* [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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).