[PATCH 0/7] Fixes for liblockdep

[PATCH 0/7] Fixes for liblockdep

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

Here are a number of fixes for liblockdep.  The first three need to
go into 4.7 and 4.6-stable; the second should probably go to all
stable branches.

Ben.

Ben Hutchings (7):
  liblockdep: Fix undefined symbol prandom_u32
  liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing
    lock_chain::depth
  liblockdep: Define the ARRAY_SIZE() macro
  liblockdep: Enable -Wall by default
  liblockdep: Fix 'unused value' warnings
  liblockdep: Fix 'set but not used' warnings
  liblockdep: Fix 'defined but not used' warning for init_utsname()

 tools/lib/lockdep/Makefile                     |  1 +
 tools/lib/lockdep/common.c                     |  6 ++++++
 tools/lib/lockdep/lockdep.c                    | 10 ++++++++++
 tools/lib/lockdep/uinclude/linux/debug_locks.h |  2 +-
 tools/lib/lockdep/uinclude/linux/irqflags.h    |  8 ++++----
 tools/lib/lockdep/uinclude/linux/kernel.h      | 14 +++++++++++---
 tools/lib/lockdep/uinclude/linux/lockdep.h     | 18 ++++++------------
 7 files changed, 39 insertions(+), 20 deletions(-)


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

[PATCH 2/7] liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1480 bytes --]

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.

Cc: <stable@vger.kernel.org> # for versions before 4.6, use a value of 255
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 tools/lib/lockdep/uinclude/linux/lockdep.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/lib/lockdep/uinclude/linux/lockdep.h b/tools/lib/lockdep/uinclude/linux/lockdep.h
index c808c7d02d21..d30214221920 100644
--- a/tools/lib/lockdep/uinclude/linux/lockdep.h
+++ b/tools/lib/lockdep/uinclude/linux/lockdep.h
@@ -8,7 +8,7 @@
 #include <linux/utsname.h>
 #include <linux/compiler.h>
 
-#define MAX_LOCK_DEPTH 2000UL
+#define MAX_LOCK_DEPTH 63UL
 
 #define asmlinkage
 #define __visible


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [PATCH 2/7] liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth

[Peter Zijlstra]

On Tue, Jun 14, 2016 at 09:47:53PM +0100, Ben Hutchings wrote:

> Even before that commit, which reduced lock_chain::depth from 8 bits
> to 6, MAX_LOCK_DEPTH was too large.

> -#define MAX_LOCK_DEPTH 2000UL
> +#define MAX_LOCK_DEPTH 63UL

So per that commit; there still is a 4 byte hole we could fill. So if a
bigger number is desired here, there is room to make that happen.

Good to see those assertions did their job, albeit somewhat belated.

Re: [PATCH 0/7] Fixes for liblockdep

[Sasha Levin]

On 06/14/2016 04:44 PM, Ben Hutchings wrote:
> Here are a number of fixes for liblockdep.  The first three need to
> go into 4.7 and 4.6-stable; the second should probably go to all
> stable branches.

Thanks Ben! I've added it all to the queue and will send it along.


Thanks,
Sasha