0d6ee0bea8
commit 98dcea0cfd04e083ac74137ceb9a632604740e2d upstream.
liblockdep has been broken since commit 75dd602a5198 ("lockdep: Fix
lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is
within the range of lock_chain::depth and in liblockdep it is much
too large.
That should have resulted in a compiler error, but didn't because:
- the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep
so is assumed to be an (undeclared) function
- putting a function call inside a BUILD_BUG_ON() expression quietly
turns it into some nonsense involving a variable-length array
It did produce a compiler warning, but I didn't notice because
liblockdep already produces too many warnings if -Wall is enabled
(which I'll fix shortly).
Even before that commit, which reduced lock_chain::depth from 8 bits
to 6, MAX_LOCK_DEPTH was too large.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||
|---|---|---|
| .. | ||
| bitops.h | ||
| compiler.h | ||
| debug_locks.h | ||
| delay.h | ||
| ftrace.h | ||
| gfp.h | ||
| hardirq.h | ||
| hash.h | ||
| interrupt.h | ||
| irqflags.h | ||
| kallsyms.h | ||
| kern_levels.h | ||
| kernel.h | ||
| kmemcheck.h | ||
| linkage.h | ||
| list.h | ||
| lockdep.h | ||
| module.h | ||
| mutex.h | ||
| poison.h | ||
| prefetch.h | ||
| proc_fs.h | ||
| rbtree_augmented.h | ||
| rcu.h | ||
| seq_file.h | ||
| spinlock.h | ||
| stacktrace.h | ||
| stringify.h | ||