* [syzbot] WARNING: suspicious RCU usage in copy_page_range
@ 2021-03-30 22:26 syzbot
2021-03-31 6:11 ` Dmitry Vyukov
0 siblings, 1 reply; 6+ messages in thread
From: syzbot @ 2021-03-30 22:26 UTC (permalink / raw)
To: akpm, axboe, christian, linux-kernel, shakeelb, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: db24726b Merge tag 'integrity-v5.12-fix' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16c16b7cd00000
kernel config: https://syzkaller.appspot.com/x/.config?x=daeff30c2474a60f
dashboard link: https://syzkaller.appspot.com/bug?extid=1a33233ccd8201ec2322
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+1a33233ccd8201ec2322@syzkaller.appspotmail.com
=============================
WARNING: suspicious RCU usage
5.12.0-rc4-syzkaller #0 Not tainted
-----------------------------
kernel/sched/core.c:8294 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
3 locks held by syz-executor.0/8401:
#0: ffffffff8c03e5b0 (dup_mmap_sem){++++}-{0:0}, at: dup_mmap kernel/fork.c:479 [inline]
#0: ffffffff8c03e5b0 (dup_mmap_sem){++++}-{0:0}, at: dup_mm+0x108/0x1380 kernel/fork.c:1368
#1: ffff888018d08858 (&mm->mmap_lock#2){++++}-{3:3}, at: mmap_write_lock_killable include/linux/mmap_lock.h:87 [inline]
#1: ffff888018d08858 (&mm->mmap_lock#2){++++}-{3:3}, at: dup_mmap kernel/fork.c:480 [inline]
#1: ffff888018d08858 (&mm->mmap_lock#2){++++}-{3:3}, at: dup_mm+0x12e/0x1380 kernel/fork.c:1368
#2: ffff88801888c058 (&mm->mmap_lock/1){+.+.}-{3:3}, at: mmap_write_lock_nested include/linux/mmap_lock.h:78 [inline]
#2: ffff88801888c058 (&mm->mmap_lock/1){+.+.}-{3:3}, at: dup_mmap kernel/fork.c:489 [inline]
#2: ffff88801888c058 (&mm->mmap_lock/1){+.+.}-{3:3}, at: dup_mm+0x18a/0x1380 kernel/fork.c:1368
stack backtrace:
CPU: 0 PID: 8401 Comm: syz-executor.0 Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:79 [inline]
dump_stack+0x141/0x1d7 lib/dump_stack.c:120
___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294
copy_pte_range mm/memory.c:1010 [inline]
copy_pmd_range mm/memory.c:1064 [inline]
copy_pud_range mm/memory.c:1101 [inline]
copy_p4d_range mm/memory.c:1125 [inline]
copy_page_range+0x1270/0x3fd0 mm/memory.c:1198
dup_mmap kernel/fork.c:594 [inline]
dup_mm+0x9ed/0x1380 kernel/fork.c:1368
copy_mm kernel/fork.c:1424 [inline]
copy_process+0x2b99/0x7150 kernel/fork.c:2107
kernel_clone+0xe7/0xab0 kernel/fork.c:2500
__do_sys_clone+0xc8/0x110 kernel/fork.c:2617
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x464a4b
Code: ed 0f 85 60 01 00 00 64 4c 8b 0c 25 10 00 00 00 45 31 c0 4d 8d 91 d0 02 00 00 31 d2 31 f6 bf 11 00 20 01 b8 38 00 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 89 00 00 00 41 89 c5 85 c0 0f 85 90 00 00
RSP: 002b:00007ffd44303270 EFLAGS: 00000246 ORIG_RAX: 0000000000000038
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000464a4b
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000001200011
RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000002e94400
R10: 0000000002e946d0 R11: 0000000000000246 R12: 0000000000000001
R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffd44303360
---
This report 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 issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] WARNING: suspicious RCU usage in copy_page_range
2021-03-30 22:26 [syzbot] WARNING: suspicious RCU usage in copy_page_range syzbot
@ 2021-03-31 6:11 ` Dmitry Vyukov
2021-03-31 7:30 ` Peter Zijlstra
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Vyukov @ 2021-03-31 6:11 UTC (permalink / raw)
To: syzbot, Peter Zijlstra, Ingo Molnar, Will Deacon
Cc: Andrew Morton, Jens Axboe, Christian Brauner, LKML, Shakeel Butt,
syzkaller-bugs
On Wed, Mar 31, 2021 at 12:26 AM syzbot
<syzbot+1a33233ccd8201ec2322@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: db24726b Merge tag 'integrity-v5.12-fix' of git://git.kern..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16c16b7cd00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=daeff30c2474a60f
> dashboard link: https://syzkaller.appspot.com/bug?extid=1a33233ccd8201ec2322
>
> 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+1a33233ccd8201ec2322@syzkaller.appspotmail.com
I think this is a LOCKDEP issue. +LOCKDEP maintainers.
Another bug happened on another thread ("WARNING: possible circular
locking dependency detected"). Lockdep disabled lock tracking
("debug_locks = 0" in the report), which probably made it miss
rcu_unlock somewhere, but it did not turn off reporting yet and
produced the false positive first.
I think if LOCKDEP disables lock tracking, it must also disable
reporting of issues that require lock tracking. That would avoid false
positives.
Some LOCKDEP-detectable bug that happens very frequently was added
recently, and syzbot got a dozen of such assorted one-off false
positive reports from LOCKDEP.
Or has something changed in LOCKDEP recently so it started producing
such false positives?
Excerpt from console output:
[ 312.003258][ T8401] =============================
[ 312.003263][ T8401] WARNING: suspicious RCU usage
[ 312.003268][ T8401] 5.12.0-rc4-syzkaller #0 Not tainted
[ 312.005611][T16839] ======================================================
[ 312.005617][T16839] WARNING: possible circular locking dependency detected
[ 312.005623][T16839] 5.12.0-rc4-syzkaller #0 Not tainted
[ 312.005631][T16839] ------------------------------------------------------
> =============================
> WARNING: suspicious RCU usage
> 5.12.0-rc4-syzkaller #0 Not tainted
> -----------------------------
> kernel/sched/core.c:8294 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
> 3 locks held by syz-executor.0/8401:
> #0: ffffffff8c03e5b0 (dup_mmap_sem){++++}-{0:0}, at: dup_mmap kernel/fork.c:479 [inline]
> #0: ffffffff8c03e5b0 (dup_mmap_sem){++++}-{0:0}, at: dup_mm+0x108/0x1380 kernel/fork.c:1368
> #1: ffff888018d08858 (&mm->mmap_lock#2){++++}-{3:3}, at: mmap_write_lock_killable include/linux/mmap_lock.h:87 [inline]
> #1: ffff888018d08858 (&mm->mmap_lock#2){++++}-{3:3}, at: dup_mmap kernel/fork.c:480 [inline]
> #1: ffff888018d08858 (&mm->mmap_lock#2){++++}-{3:3}, at: dup_mm+0x12e/0x1380 kernel/fork.c:1368
> #2: ffff88801888c058 (&mm->mmap_lock/1){+.+.}-{3:3}, at: mmap_write_lock_nested include/linux/mmap_lock.h:78 [inline]
> #2: ffff88801888c058 (&mm->mmap_lock/1){+.+.}-{3:3}, at: dup_mmap kernel/fork.c:489 [inline]
> #2: ffff88801888c058 (&mm->mmap_lock/1){+.+.}-{3:3}, at: dup_mm+0x18a/0x1380 kernel/fork.c:1368
>
> stack backtrace:
> CPU: 0 PID: 8401 Comm: syz-executor.0 Not tainted 5.12.0-rc4-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:79 [inline]
> dump_stack+0x141/0x1d7 lib/dump_stack.c:120
> ___might_sleep+0x229/0x2c0 kernel/sched/core.c:8294
> copy_pte_range mm/memory.c:1010 [inline]
> copy_pmd_range mm/memory.c:1064 [inline]
> copy_pud_range mm/memory.c:1101 [inline]
> copy_p4d_range mm/memory.c:1125 [inline]
> copy_page_range+0x1270/0x3fd0 mm/memory.c:1198
> dup_mmap kernel/fork.c:594 [inline]
> dup_mm+0x9ed/0x1380 kernel/fork.c:1368
> copy_mm kernel/fork.c:1424 [inline]
> copy_process+0x2b99/0x7150 kernel/fork.c:2107
> kernel_clone+0xe7/0xab0 kernel/fork.c:2500
> __do_sys_clone+0xc8/0x110 kernel/fork.c:2617
> do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xae
> RIP: 0033:0x464a4b
> Code: ed 0f 85 60 01 00 00 64 4c 8b 0c 25 10 00 00 00 45 31 c0 4d 8d 91 d0 02 00 00 31 d2 31 f6 bf 11 00 20 01 b8 38 00 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 89 00 00 00 41 89 c5 85 c0 0f 85 90 00 00
> RSP: 002b:00007ffd44303270 EFLAGS: 00000246 ORIG_RAX: 0000000000000038
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000464a4b
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000001200011
> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000002e94400
> R10: 0000000002e946d0 R11: 0000000000000246 R12: 0000000000000001
> R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffd44303360
>
>
> ---
> This report 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 issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/00000000000086695705bec87c9f%40google.com.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] WARNING: suspicious RCU usage in copy_page_range
2021-03-31 6:11 ` Dmitry Vyukov
@ 2021-03-31 7:30 ` Peter Zijlstra
2021-03-31 9:57 ` Dmitry Vyukov
0 siblings, 1 reply; 6+ messages in thread
From: Peter Zijlstra @ 2021-03-31 7:30 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, Ingo Molnar, Will Deacon, Andrew Morton, Jens Axboe,
Christian Brauner, LKML, Shakeel Butt, syzkaller-bugs
On Wed, Mar 31, 2021 at 08:11:38AM +0200, Dmitry Vyukov wrote:
> On Wed, Mar 31, 2021 at 12:26 AM syzbot
> <syzbot+1a33233ccd8201ec2322@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: db24726b Merge tag 'integrity-v5.12-fix' of git://git.kern..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=16c16b7cd00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=daeff30c2474a60f
> > dashboard link: https://syzkaller.appspot.com/bug?extid=1a33233ccd8201ec2322
> >
> > 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+1a33233ccd8201ec2322@syzkaller.appspotmail.com
>
> I think this is a LOCKDEP issue. +LOCKDEP maintainers.
>
> Another bug happened on another thread ("WARNING: possible circular
> locking dependency detected"). Lockdep disabled lock tracking
> ("debug_locks = 0" in the report), which probably made it miss
> rcu_unlock somewhere, but it did not turn off reporting yet and
> produced the false positive first.
>
> I think if LOCKDEP disables lock tracking, it must also disable
> reporting of issues that require lock tracking. That would avoid false
> positives.
Still early and brain hasn't really booted yet, but features that
require lock tracking are supposed to check debug_locks.
And afaict debug_lockdep_rcu_enabled(), which is called by
RCU_LOCKDEP_WARN(), which is called by rcu_sleep_check() does just that.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] WARNING: suspicious RCU usage in copy_page_range
2021-03-31 7:30 ` Peter Zijlstra
@ 2021-03-31 9:57 ` Dmitry Vyukov
2021-04-06 7:41 ` Peter Zijlstra
0 siblings, 1 reply; 6+ messages in thread
From: Dmitry Vyukov @ 2021-03-31 9:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: syzbot, Ingo Molnar, Will Deacon, Andrew Morton, Jens Axboe,
Christian Brauner, LKML, Shakeel Butt, syzkaller-bugs
On Wed, Mar 31, 2021 at 9:31 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, Mar 31, 2021 at 08:11:38AM +0200, Dmitry Vyukov wrote:
> > On Wed, Mar 31, 2021 at 12:26 AM syzbot
> > <syzbot+1a33233ccd8201ec2322@syzkaller.appspotmail.com> wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit: db24726b Merge tag 'integrity-v5.12-fix' of git://git.kern..
> > > git tree: upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=16c16b7cd00000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=daeff30c2474a60f
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=1a33233ccd8201ec2322
> > >
> > > 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+1a33233ccd8201ec2322@syzkaller.appspotmail.com
> >
> > I think this is a LOCKDEP issue. +LOCKDEP maintainers.
> >
> > Another bug happened on another thread ("WARNING: possible circular
> > locking dependency detected"). Lockdep disabled lock tracking
> > ("debug_locks = 0" in the report), which probably made it miss
> > rcu_unlock somewhere, but it did not turn off reporting yet and
> > produced the false positive first.
> >
> > I think if LOCKDEP disables lock tracking, it must also disable
> > reporting of issues that require lock tracking. That would avoid false
> > positives.
>
> Still early and brain hasn't really booted yet, but features that
> require lock tracking are supposed to check debug_locks.
>
> And afaict debug_lockdep_rcu_enabled(), which is called by
> RCU_LOCKDEP_WARN(), which is called by rcu_sleep_check() does just that.
Right... yet it somehow happens.
Looking at a dozen of reports, all with 2 concurrent lockdep splats
and "debug_locks = 0" in the report, I am pretty sure there is some
kind of race in lockdep.
I see there are at least 2 places where lockdep can falsely assume rcu
lock is held:
https://elixir.bootlin.com/linux/v5.12-rc5/source/kernel/locking/lockdep.c#L5543
https://elixir.bootlin.com/linux/v5.12-rc5/source/kernel/rcu/update.c#L105
both to "avoid false positives", but for "Illegal context switch in
RCU-bh read-side critical section" it can actually lead to false
positives, right?
Is there something else that turns off tracking before setting
debug_locks=0? Perhaps we get into that window where tracking is
disabled, but debug_locks is not reset yet?
lockdep_enabled() returns false if lockdep_recursion var is set:
https://elixir.bootlin.com/linux/v5.12-rc5/source/kernel/locking/lockdep.c#L87
but lockdep_lock() sets it _before_ taking the lock:
https://elixir.bootlin.com/linux/v5.12-rc5/source/kernel/locking/lockdep.c#L111
Is it possible that lockdep_recursion is set, then the task is
rescheduled and another task sees wrong value for lockdep_recursion?
Shouldn't lockdep_recursion be set _after_ arch_spin_unlock(&__lock)?
Though, I assume lockdep_lock() is called frequently and not only on
reports, so if my reasoning would be true, it would produce false
positives all the time, not necessary on concurrent reports... this
does not agree with the observed failure mode...
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] WARNING: suspicious RCU usage in copy_page_range
2021-03-31 9:57 ` Dmitry Vyukov
@ 2021-04-06 7:41 ` Peter Zijlstra
2021-04-13 18:12 ` Dmitry Vyukov
0 siblings, 1 reply; 6+ messages in thread
From: Peter Zijlstra @ 2021-04-06 7:41 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, Ingo Molnar, Will Deacon, Andrew Morton, Jens Axboe,
Christian Brauner, LKML, Shakeel Butt, syzkaller-bugs
On Wed, Mar 31, 2021 at 11:57:23AM +0200, Dmitry Vyukov wrote:
> On Wed, Mar 31, 2021 at 9:31 AM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Wed, Mar 31, 2021 at 08:11:38AM +0200, Dmitry Vyukov wrote:
> > > On Wed, Mar 31, 2021 at 12:26 AM syzbot
> > > <syzbot+1a33233ccd8201ec2322@syzkaller.appspotmail.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > syzbot found the following issue on:
> > > >
> > > > HEAD commit: db24726b Merge tag 'integrity-v5.12-fix' of git://git.kern..
> > > > git tree: upstream
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=16c16b7cd00000
> > > > kernel config: https://syzkaller.appspot.com/x/.config?x=daeff30c2474a60f
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=1a33233ccd8201ec2322
> > > >
> > > > 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+1a33233ccd8201ec2322@syzkaller.appspotmail.com
> > >
> > > I think this is a LOCKDEP issue. +LOCKDEP maintainers.
> > >
> > > Another bug happened on another thread ("WARNING: possible circular
> > > locking dependency detected"). Lockdep disabled lock tracking
> > > ("debug_locks = 0" in the report), which probably made it miss
> > > rcu_unlock somewhere, but it did not turn off reporting yet and
> > > produced the false positive first.
> > >
> > > I think if LOCKDEP disables lock tracking, it must also disable
> > > reporting of issues that require lock tracking. That would avoid false
> > > positives.
> >
> > Still early and brain hasn't really booted yet, but features that
> > require lock tracking are supposed to check debug_locks.
> >
> > And afaict debug_lockdep_rcu_enabled(), which is called by
> > RCU_LOCKDEP_WARN(), which is called by rcu_sleep_check() does just that.
>
> Right... yet it somehow happens.
> Looking at a dozen of reports, all with 2 concurrent lockdep splats
> and "debug_locks = 0" in the report, I am pretty sure there is some
> kind of race in lockdep.
Aah, concurrent splats. Yes, that was per design. The theory was that
concurrent splats are rare and this is much simpler code.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] WARNING: suspicious RCU usage in copy_page_range
2021-04-06 7:41 ` Peter Zijlstra
@ 2021-04-13 18:12 ` Dmitry Vyukov
0 siblings, 0 replies; 6+ messages in thread
From: Dmitry Vyukov @ 2021-04-13 18:12 UTC (permalink / raw)
To: Peter Zijlstra
Cc: syzbot, Ingo Molnar, Will Deacon, Andrew Morton, Jens Axboe,
Christian Brauner, LKML, Shakeel Butt, syzkaller-bugs
On Tue, Apr 6, 2021 at 9:41 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Wed, Mar 31, 2021 at 11:57:23AM +0200, Dmitry Vyukov wrote:
> > On Wed, Mar 31, 2021 at 9:31 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Wed, Mar 31, 2021 at 08:11:38AM +0200, Dmitry Vyukov wrote:
> > > > On Wed, Mar 31, 2021 at 12:26 AM syzbot
> > > > <syzbot+1a33233ccd8201ec2322@syzkaller.appspotmail.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > syzbot found the following issue on:
> > > > >
> > > > > HEAD commit: db24726b Merge tag 'integrity-v5.12-fix' of git://git.kern..
> > > > > git tree: upstream
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=16c16b7cd00000
> > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=daeff30c2474a60f
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=1a33233ccd8201ec2322
> > > > >
> > > > > 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+1a33233ccd8201ec2322@syzkaller.appspotmail.com
> > > >
> > > > I think this is a LOCKDEP issue. +LOCKDEP maintainers.
> > > >
> > > > Another bug happened on another thread ("WARNING: possible circular
> > > > locking dependency detected"). Lockdep disabled lock tracking
> > > > ("debug_locks = 0" in the report), which probably made it miss
> > > > rcu_unlock somewhere, but it did not turn off reporting yet and
> > > > produced the false positive first.
> > > >
> > > > I think if LOCKDEP disables lock tracking, it must also disable
> > > > reporting of issues that require lock tracking. That would avoid false
> > > > positives.
> > >
> > > Still early and brain hasn't really booted yet, but features that
> > > require lock tracking are supposed to check debug_locks.
> > >
> > > And afaict debug_lockdep_rcu_enabled(), which is called by
> > > RCU_LOCKDEP_WARN(), which is called by rcu_sleep_check() does just that.
> >
> > Right... yet it somehow happens.
> > Looking at a dozen of reports, all with 2 concurrent lockdep splats
> > and "debug_locks = 0" in the report, I am pretty sure there is some
> > kind of race in lockdep.
>
> Aah, concurrent splats. Yes, that was per design. The theory was that
> concurrent splats are rare and this is much simpler code.
#syz dup: WARNING: suspicious RCU usage in getname_flags
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-04-13 18:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-30 22:26 [syzbot] WARNING: suspicious RCU usage in copy_page_range syzbot
2021-03-31 6:11 ` Dmitry Vyukov
2021-03-31 7:30 ` Peter Zijlstra
2021-03-31 9:57 ` Dmitry Vyukov
2021-04-06 7:41 ` Peter Zijlstra
2021-04-13 18:12 ` Dmitry Vyukov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.