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

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

[syzbot]

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: 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
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 syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

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

[Ritesh Harjani]

[-- Attachment #1: Type: text/plain, Size: 122 bytes --]

#syz test: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 
0e21d4620dd047da7952f44a2e1ac777ded2d57e

[-- Attachment #2: 0001-ext4-mballoc-Use-raw_cpu_ptr-in-case-if-preemption-i.patch --]
[-- Type: text/x-patch, Size: 2346 bytes --]

From cc1cf67d99d5fa61db0651c89c288df31bad6b8e Mon Sep 17 00:00:00 2001
From: Ritesh Harjani <riteshh@linux.ibm.com>
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 <riteshh@linux.ibm.com>
Reported-by: syzbot+82f324bb69744c5f6969@syzkaller.appspotmail.com
---
 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

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

[syzbot]

> #syz test: 

This crash does not have a reproducer. I cannot test it.

> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 
> 0e21d4620dd047da7952f44a2e1ac777ded2d57e

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

[Ido Schimmel]

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 <riteshh@linux.ibm.com>
> 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 <riteshh@linux.ibm.com>
> Reported-by: syzbot+82f324bb69744c5f6969@syzkaller.appspotmail.com

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
> 

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

[Ritesh Harjani]

On 6/12/20 6:13 PM, Ido Schimmel wrote:
> 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 <riteshh@linux.ibm.com>
>> 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 <riteshh@linux.ibm.com>
>> Reported-by: syzbot+82f324bb69744c5f6969@syzkaller.appspotmail.com
> 
> Hi,
> 
> Are you going to submit this patch formally? Without it I'm constantly
> seeing the above splat.
> 

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


-ritesh

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

[Ido Schimmel]

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.

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

[Ritesh Harjani]

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