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;
Date:   Tue, 14 Jan 2020 09:43:34 +0100
From:   Peter Zijlstra <peterz@infradead.org>
To:     Dmitry Vyukov <dvyukov@google.com>
Cc:     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>
Subject: Re: BUG: MAX_LOCKDEP_CHAINS too low!
Message-ID: <20200114084334.GI2827@hirez.programming.kicks-ass.net>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACT4Y+ZBYYUiJejNbPcZWS+aHehvkgKkTKm0gvuviXGGcirJ5g@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Jan 09, 2020 at 11:59:25AM +0100, Dmitry Vyukov wrote:

> Or are there some ID leaks in lockdep? syzbot has a bunch of very
> simple reproducers for these bugs, so not really a maximally diverse
> load. And I think I saw these bugs massively when testing just a
> single subsystem too, e.g. netfilter.

Can you share me one of the simple ones? A .c files I can run on my
regular test box that should make it go *splat* ?

Often in the past hitting these limits was the result of some
particularly poor annotation.

For instance, locks in per-cpu data used to trigger this, since
static locks don't need explicit {mutex,spin_lock}_init() calls and
instead use their (static) address. This worked fine for global state,
but per-cpu is an exception, there it causes a nr_cpus explosion in
lockdep state because you get nr_cpus different addresses.

Now, we fixed that particular issue:

  383776fa7527 ("locking/lockdep: Handle statically initialized PER_CPU locks properly")

but maybe there's something else going on.

Just blindly bumping the number without analysis of what exactly is
happening is never a good idea.