linux-kernel - Re: BUG: MAX_LOCKDEP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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!