Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1650458 > unrolled thread
| Started by | "Levin, Alexander (Sasha Levin)" <alexander.levin@verizon.com> |
|---|---|
| First post | 2017-05-25 15:00 +0200 |
| Last post | 2017-06-05 11:10 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH 02/21] liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth "Levin, Alexander (Sasha Levin)" <alexander.levin@verizon.com> - 2017-05-25 15:00 +0200
[tip:locking/core] tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth tip-bot for Ben Hutchings <tipbot@zytor.com> - 2017-06-05 11:10 +0200
| From | "Levin, Alexander (Sasha Levin)" <alexander.levin@verizon.com> |
|---|---|
| Date | 2017-05-25 15:00 +0200 |
| Subject | [PATCH 02/21] liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth |
| Message-ID | <tL0wV-8li-7@gated-at.bofh.it> |
From: Ben Hutchings <ben@decadent.org.uk>
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>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
---
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
--
2.11.0
[toc] | [next] | [standalone]
| From | tip-bot for Ben Hutchings <tipbot@zytor.com> |
|---|---|
| Date | 2017-06-05 11:10 +0200 |
| Subject | [tip:locking/core] tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth |
| Message-ID | <tOWbp-Zl-35@gated-at.bofh.it> |
| In reply to | #1650458 |
Commit-ID: 98dcea0cfd04e083ac74137ceb9a632604740e2d
Gitweb: http://git.kernel.org/tip/98dcea0cfd04e083ac74137ceb9a632604740e2d
Author: Ben Hutchings <ben@decadent.org.uk>
AuthorDate: Thu, 25 May 2017 12:58:33 +0000
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 5 Jun 2017 09:28:03 +0200
tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth
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: <stable@vger.kernel.org> # for versions before 4.6, use a value of 255
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>
---
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 c808c7d..d302142 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
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web