On Thu, Dec 17, 2020 at 09:26:44AM +0100, Dmitry Vyukov wrote: > On Wed, Dec 16, 2020 at 9:55 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > On Wed, Dec 16, 2020 at 11:34:10AM -0800, syzbot wrote: > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+51ce7a5794c3b12a70d1@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > ============================= > > > WARNING: suspicious RCU usage > > > 5.10.0-rc7-syzkaller #0 Not tainted > > > ----------------------------- > > > kernel/sched/core.c:7270 Illegal context switch in RCU-bh read-side critical section! > > > > > > other info that might help us debug this: > > > > > > > > > rcu_scheduler_active = 2, debug_locks = 0 > > > no locks held by udevd/9038. > > > > > > stack backtrace: > > > CPU: 3 PID: 9038 Comm: udevd Not tainted 5.10.0-rc7-syzkaller #0 > > > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 > > > Call Trace: > > > __dump_stack lib/dump_stack.c:77 [inline] > > > dump_stack+0x107/0x163 lib/dump_stack.c:118 > > > ___might_sleep+0x220/0x2b0 kernel/sched/core.c:7270 > > > count.constprop.0+0x164/0x270 fs/exec.c:449 > > > do_execveat_common+0x2fd/0x7c0 fs/exec.c:1893 > > > do_execve fs/exec.c:1983 [inline] > > > __do_sys_execve fs/exec.c:2059 [inline] > > > __se_sys_execve fs/exec.c:2054 [inline] > > > __x64_sys_execve+0x8f/0xc0 fs/exec.c:2054 > > > do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 > > > > This must be the victim of something else. There's no way this call > > trace took the RCU read lock. > > +lockdep maintainers for lockdep false positive then and +Paul for rcu Note that this was "RCU-bh" rather than "RCU", so it might be something like local_bh_disable() rather than rcu_read_lock() that might_sleep() is complaining about. > There is another recent claim of a false "suspicious RCU usage": > https://lore.kernel.org/lkml/CAKMK7uEiS5SrBYv-2w2wWL=9G4ByoHvtiWVsPqekswZzOGmzjg@xxxxxxxxxxxxxx/ That one does look familiar. ;-) Thanx, Paul
