Re: linux-next test error: BUG: using smp_processor_id() in preemptible [ADDR] code: syz-fuzzer/6792

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@xxxxxxxxxxxxxxxxxxxxxxxxx

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



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux