Messages in this thread | | | Subject | Re: linux-next test error: BUG: using smp_processor_id() in preemptible [ADDR] code: syz-fuzzer/6792 | From | Ritesh Harjani <> | Date | Wed, 3 Jun 2020 15:36:47 +0530 |
| |
On 6/2/20 8:22 PM, Hillf Danton wrote: > > Tue, 02 Jun 2020 04:20:16 -0700 >> syzbot found the following crash on: >> >> HEAD commit: 0e21d462 Add linux-next specific files for 20200602 >> git tree: linux-next >> console output: https://syzkaller.appspot.com/x/log.txt?x=127233ee100000 >> kernel config: https://syzkaller.appspot.com/x/.config?x=ecc1aef35f550ee3 >> dashboard link: https://syzkaller.appspot.com/bug?extid=82f324bb69744c5f6969 >> compiler: gcc (GCC) 9.0.0 20181231 (experimental) >> >> IMPORTANT: if you fix the bug, please add the following tag to the commit: >> Reported-by: syzbot+82f324bb69744c5f6969@syzkaller.appspotmail.com >> >> BUG: using smp_processor_id() in preemptible [00000000] code: syz-fuzzer/6792 >> caller is ext4_mb_new_blocks+0xa4d/0x3b70 fs/ext4/mballoc.c:4711 > > Fix 42f56b7a4a7d ("ext4: mballoc: introduce pcpu seqcnt for freeing PA > to improve ENOSPC handling") by redefining discard_pa_seq to be a simple > regular sequence counter to axe the need of percpu operation.
Why remove percpu seqcnt? IIUC, percpu are much better in case of a multi-threaded use case which could run and allocate blocks in parallel. Whereas a updating a simple variable across different cpus may lead to cacheline bouncing problem. Since in this case we can very well have a use case of multiple threads trying to allocate blocks at the same time, so why change this to a simple seqcnt from percpu seqcnt?
-ritesh
| |