[PATCH 3.16 014/192] tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth
3.16.49-rc1 review patch. If anyone has any objections, please let me know. -- From: Ben Hutchingscommit 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 Signed-off-by: Sasha Levin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: a.p.zijls...@chello.nl Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.le...@verizon.com Signed-off-by: Ingo Molnar --- tools/lib/lockdep/uinclude/linux/lockdep.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/lib/lockdep/uinclude/linux/lockdep.h +++ b/tools/lib/lockdep/uinclude/linux/lockdep.h @@ -8,7 +8,7 @@ #include -#define MAX_LOCK_DEPTH 2000UL +#define MAX_LOCK_DEPTH 255UL #define asmlinkage #define __visible
[PATCH 3.16 014/192] tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth
3.16.49-rc1 review patch. If anyone has any objections, please let me know. -- From: Ben Hutchings 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 Signed-off-by: Sasha Levin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: a.p.zijls...@chello.nl Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.le...@verizon.com Signed-off-by: Ingo Molnar --- tools/lib/lockdep/uinclude/linux/lockdep.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/lib/lockdep/uinclude/linux/lockdep.h +++ b/tools/lib/lockdep/uinclude/linux/lockdep.h @@ -8,7 +8,7 @@ #include -#define MAX_LOCK_DEPTH 2000UL +#define MAX_LOCK_DEPTH 255UL #define asmlinkage #define __visible