[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+Y5+wma84Gofcm86KvOKw2niybPBTwz8iHzYW-ndFHH8g@mail.gmail.com>
Date: Thu, 16 Jan 2020 18:05:26 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Taehee Yoo <ap420073@...il.com>
Cc: Cong Wang <xiyou.wangcong@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
syzbot <syzbot+aaa6fa4949cc5d9b7b25@...kaller.appspotmail.com>,
Ingo Molnar <mingo@...nel.org>,
Will Deacon <will.deacon@....com>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: BUG: MAX_LOCKDEP_CHAINS too low!
On Thu, Jan 16, 2020 at 4:33 PM Taehee Yoo <ap420073@...il.com> wrote:
>
> On Thu, 16 Jan 2020 at 14:25, Dmitry Vyukov <dvyukov@...gle.com> wrote:
> >
>
> Hi Dmitry!
>
> > On Wed, Jan 15, 2020 at 10:53 PM Cong Wang <xiyou.wangcong@...il.com> wrote:
> > > > +Taehee, Cong,
> > > >
> > > > In the other thread Taehee mentioned the creation of dynamic keys for
> > > > net devices that was added recently and that they are subject to some
> > > > limits.
> > > > syzkaller creates lots of net devices for isolation (several dozens
> > > > per test process, but then these can be created and destroyed
> > > > periodically). I wonder if it's the root cause of the lockdep limits
> > > > problems?
> > >
> > > Very possibly. In current code base, there are 4 lockdep keys
> > > per netdev:
> > >
> > > struct lock_class_key qdisc_tx_busylock_key;
> > > struct lock_class_key qdisc_running_key;
> > > struct lock_class_key qdisc_xmit_lock_key;
> > > struct lock_class_key addr_list_lock_key;
> > >
> > > so the number of lockdep keys is at least 4x number of network
> > > devices.
> >
> > And these are not freed/reused, right? So with dynamic keys LOCKDEP
> > inherently can't handle prolonged running, only O(1) work?
>
> When netdev interface is removed, these dynamic keys are removed.
> But if so many netdev interfaces are existing concurrently
> (more than 2000), lockdep will stop because of a lack of keys.
> In addition, as far as I know, freeing dynamic lockdep key routine is
> slower than creating a new dynamic lockdep key. If there are so many
> netdev interface add/delete operations, for a while, there may be no
> available lockdep key. At this moment, lockdep will stop.
>
> Thank you
> Taehee Yoo
This issues mostly stalled all syzbot testing by now, these LOCKDEP
bugs are the only bugs that are being detected...
2020/01/16 15:30:47 vm-2: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/01/16 15:38:28 vm-3: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
2020/01/16 15:39:55 vm-0: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
2020/01/16 15:41:19 vm-6: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
2020/01/16 15:41:35 vm-1: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
2020/01/16 15:51:16 vm-2: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/01/16 15:57:52 vm-4: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/01/16 16:00:57 vm-6: crash: BUG: MAX_LOCKDEP_ENTRIES too low!
2020/01/16 16:36:35 vm-1: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
2020/01/16 16:37:04 vm-3: crash: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
Powered by blists - more mailing lists