On Tue, Apr 6, 2021 at 9:41 AM Peter Zijlstra <pet...@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 <pet...@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+1a33233ccd8201ec2...@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+1a33233ccd8201ec2...@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