lkml.org 
[lkml]   [2020]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: BUG: MAX_LOCKDEP_CHAINS too low!
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.

\
 
 \ /
  Last update: 2020-01-14 09:44    [W:0.304 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site