Hello,
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: [email protected]
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
CPU: 1 PID: 6792 Comm: syz-fuzzer Not tainted 5.7.0-next-20200602-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x18f/0x20d lib/dump_stack.c:118
check_preemption_disabled+0x20d/0x220 lib/smp_processor_id.c:48
ext4_mb_new_blocks+0xa4d/0x3b70 fs/ext4/mballoc.c:4711
ext4_ext_map_blocks+0x201b/0x33e0 fs/ext4/extents.c:4244
ext4_map_blocks+0x4cb/0x1640 fs/ext4/inode.c:626
ext4_getblk+0xad/0x520 fs/ext4/inode.c:833
ext4_bread+0x7c/0x380 fs/ext4/inode.c:883
ext4_append+0x153/0x360 fs/ext4/namei.c:67
ext4_init_new_dir fs/ext4/namei.c:2757 [inline]
ext4_mkdir+0x5e0/0xdf0 fs/ext4/namei.c:2802
vfs_mkdir+0x419/0x690 fs/namei.c:3632
do_mkdirat+0x21e/0x280 fs/namei.c:3655
do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4b02a0
Code: Bad RIP value.
RSP: 002b:000000c00010d4b8 EFLAGS: 00000212 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 000000c00002c000 RCX: 00000000004b02a0
RDX: 00000000000001c0 RSI: 000000c000026b40 RDI: ffffffffffffff9c
RBP: 000000c00010d510 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000212 R12: ffffffffffffffff
R13: 000000000000005b R14: 000000000000005a R15: 0000000000000100
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
#syz test:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
0e21d4620dd047da7952f44a2e1ac777ded2d57e
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: [email protected]
>>
>> 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
On Tue, Jun 02, 2020 at 06:11:29PM +0530, Ritesh Harjani wrote:
> #syz test:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> 0e21d4620dd047da7952f44a2e1ac777ded2d57e
> >From cc1cf67d99d5fa61db0651c89c288df31bad6b8e Mon Sep 17 00:00:00 2001
> From: Ritesh Harjani <[email protected]>
> Date: Tue, 2 Jun 2020 17:54:12 +0530
> Subject: [PATCH 1/1] ext4: mballoc: Use raw_cpu_ptr in case if preemption is enabled
>
> It doesn't matter really in ext4_mb_new_blocks() about whether the code
> is rescheduled on any other cpu due to preemption. Because we care
> about discard_pa_seq only when the block allocation fails and then too
> we add the seq counter of all the cpus against the initial sampled one
> to check if anyone has freed any blocks while we were doing allocation.
>
> So just use raw_cpu_ptr to not trigger this BUG.
>
> BUG: using smp_processor_id() in preemptible [00000000] code: syz-fuzzer/6927
> caller is ext4_mb_new_blocks+0xa4d/0x3b70 fs/ext4/mballoc.c:4711
> CPU: 1 PID: 6927 Comm: syz-fuzzer Not tainted 5.7.0-next-20200602-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x18f/0x20d lib/dump_stack.c:118
> check_preemption_disabled+0x20d/0x220 lib/smp_processor_id.c:48
> ext4_mb_new_blocks+0xa4d/0x3b70 fs/ext4/mballoc.c:4711
> ext4_ext_map_blocks+0x201b/0x33e0 fs/ext4/extents.c:4244
> ext4_map_blocks+0x4cb/0x1640 fs/ext4/inode.c:626
> ext4_getblk+0xad/0x520 fs/ext4/inode.c:833
> ext4_bread+0x7c/0x380 fs/ext4/inode.c:883
> ext4_append+0x153/0x360 fs/ext4/namei.c:67
> ext4_init_new_dir fs/ext4/namei.c:2757 [inline]
> ext4_mkdir+0x5e0/0xdf0 fs/ext4/namei.c:2802
> vfs_mkdir+0x419/0x690 fs/namei.c:3632
> do_mkdirat+0x21e/0x280 fs/namei.c:3655
> do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> Signed-off-by: Ritesh Harjani <[email protected]>
> Reported-by: [email protected]
Hi,
Are you going to submit this patch formally? Without it I'm constantly
seeing the above splat.
Thanks
> ---
> fs/ext4/mballoc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
> index a9083113a8c0..b79b32dbe3ea 100644
> --- a/fs/ext4/mballoc.c
> +++ b/fs/ext4/mballoc.c
> @@ -4708,7 +4708,7 @@ ext4_fsblk_t ext4_mb_new_blocks(handle_t *handle,
> }
>
> ac->ac_op = EXT4_MB_HISTORY_PREALLOC;
> - seq = *this_cpu_ptr(&discard_pa_seq);
> + seq = *raw_cpu_ptr(&discard_pa_seq);
> if (!ext4_mb_use_preallocated(ac)) {
> ac->ac_op = EXT4_MB_HISTORY_ALLOC;
> ext4_mb_normalize_request(ac, ar);
> --
> 2.21.3
>
On Fri, Jun 12, 2020 at 07:09:04PM +0530, Ritesh Harjani wrote:
> I see Ted has already taken v2 of this patch in his dev repo.
> Should be able to see in linux tree soon.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=dev&id=811985365378df01386c3cfb7ff716e74ca376d5
Great, thanks a lot. I've replaced previous patch with this one in my
testing tree.