Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <0000000000007523a60576e80a47@google.com> <CACT4Y+b3AmVQMjPNsPHOXRZS4tNYb6Z9h5-c=1ZwZk0VR-5J5Q@mail.gmail.com>
 <20180928070042.GF3439@hirez.programming.kicks-ass.net> <CACT4Y+YFmSmXjs5EMNRPvsR-mLYeAYKypBppYq_M_boTi8a9uQ@mail.gmail.com>
 <CACT4Y+ZBYYUiJejNbPcZWS+aHehvkgKkTKm0gvuviXGGcirJ5g@mail.gmail.com>
 <CACT4Y+bTGp1J9Wn=93LUObdTcWPo2JrChYKF-1v6aXmtvoQgPQ@mail.gmail.com>
 <CAM_iQpVtcNFeEtW15z_nZoyC1Q-_pCq+UfZ4vYBB3Lb2CMm4Mg@mail.gmail.com> <CACT4Y+YuM55YUT37jwRP163J7ha25cN03sZ5WqTUPkz3e43Ggw@mail.gmail.com>
In-Reply-To: <CACT4Y+YuM55YUT37jwRP163J7ha25cN03sZ5WqTUPkz3e43Ggw@mail.gmail.com>
From:   Taehee Yoo <ap420073@gmail.com>
Date:   Fri, 17 Jan 2020 00:32:55 +0900
Message-ID: <CAMArcTXq=nV5kNSdWPgvpMmYXuet9gxZgmxO2JJJ7_T3vLRoRg@mail.gmail.com>
Subject: Re: BUG: MAX_LOCKDEP_CHAINS too low!
To:     Dmitry Vyukov <dvyukov@google.com>
Cc:     Cong Wang <xiyou.wangcong@gmail.com>,
        Peter Zijlstra <peterz@infradead.org>,
        syzbot <syzbot+aaa6fa4949cc5d9b7b25@syzkaller.appspotmail.com>,
        Ingo Molnar <mingo@kernel.org>,
        Will Deacon <will.deacon@arm.com>,
        LKML <linux-kernel@vger.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
        Thomas Gleixner <tglx@linutronix.de>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 16 Jan 2020 at 14:25, Dmitry Vyukov <dvyukov@google.com> wrote:
>

Hi Dmitry!

> On Wed, Jan 15, 2020 at 10:53 PM Cong Wang <xiyou.wangcong@gmail.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