[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YGwQlnpKBbUrGaZm@hirez.programming.kicks-ass.net>
Date: Tue, 6 Apr 2021 09:41:10 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: syzbot <syzbot+1a33233ccd8201ec2322@...kaller.appspotmail.com>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Jens Axboe <axboe@...nel.dk>,
Christian Brauner <christian@...uner.io>,
LKML <linux-kernel@...r.kernel.org>,
Shakeel Butt <shakeelb@...gle.com>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: [syzbot] WARNING: suspicious RCU usage in copy_page_range
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@...radead.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@...kaller.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@...kaller.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.
Powered by blists - more mailing lists