[PATCH 5.10 0/1] Backport support for tracing capacity constants

[PATCH 5.10 0/1] Backport support for tracing capacity constants

[Alexey Khoroshilov]

Syzkaller reports a number of "BUG: MAX_LOCKDEP_CHAINS too low!" warnings
on 5.10 branch and it means that the fuzz testing is terminated prematurely.
Since upstream patch that allows to increase limits is applied cleanly
and our testing demonstrated that it works well, we suggest to backport
it to the 5.10 branch.

--
Alexey

[PATCH 5.10 1/1] lockdep: Allow tuning tracing capacity constants.

[Alexey Khoroshilov]

From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

commit 41fc8a7ca0beca32af0ac6bb0043618dcda967b1 upstream.

Since syzkaller continues various test cases until the kernel crashes,
syzkaller tends to examine more locking dependencies than normal systems.
As a result, syzbot is reporting that the fuzz testing was terminated
due to hitting upper limits lockdep can track [1] [2] [3]. Since analysis
via /proc/lockdep* did not show any obvious culprit [4] [5], we have no
choice but allow tuning tracing capacity constants.

[1] https://syzkaller.appspot.com/bug?id=3d97ba93fb3566000c1c59691ea427370d33ea1b
[2] https://syzkaller.appspot.com/bug?id=381cb436fe60dc03d7fd2a092b46d7f09542a72a
[3] https://syzkaller.appspot.com/bug?id=a588183ac34c1437fc0785e8f220e88282e5a29f
[4] https://lkml.kernel.org/r/4b8f7a57-fa20-47bd-48a0-ae35d860f233@i-love.sakura.ne.jp
[5] https://lkml.kernel.org/r/1c351187-253b-2d49-acaf-4563c63ae7d2@i-love.sakura.ne.jp

References: https://lkml.kernel.org/r/1595640639-9310-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
---
 kernel/locking/lockdep.c           |  2 +-
 kernel/locking/lockdep_internals.h |  8 ++++----
 lib/Kconfig.debug                  | 40 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 45 insertions(+), 5 deletions(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index b6683ce..c3387cd 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -1397,7 +1397,7 @@ static int add_lock_to_list(struct lock_class *this,
 /*
  * For good efficiency of modular, we use power of 2
  */
-#define MAX_CIRCULAR_QUEUE_SIZE		4096UL
+#define MAX_CIRCULAR_QUEUE_SIZE		(1UL << CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS)
 #define CQ_MASK				(MAX_CIRCULAR_QUEUE_SIZE-1)
 
 /*
diff --git a/kernel/locking/lockdep_internals.h b/kernel/locking/lockdep_internals.h
index a19b016..bbe9000 100644
--- a/kernel/locking/lockdep_internals.h
+++ b/kernel/locking/lockdep_internals.h
@@ -99,16 +99,16 @@ static const unsigned long LOCKF_USED_IN_IRQ_READ =
 #define MAX_STACK_TRACE_ENTRIES	262144UL
 #define STACK_TRACE_HASH_SIZE	8192
 #else
-#define MAX_LOCKDEP_ENTRIES	32768UL
+#define MAX_LOCKDEP_ENTRIES	(1UL << CONFIG_LOCKDEP_BITS)
 
-#define MAX_LOCKDEP_CHAINS_BITS	16
+#define MAX_LOCKDEP_CHAINS_BITS	CONFIG_LOCKDEP_CHAINS_BITS
 
 /*
  * Stack-trace: tightly packed array of stack backtrace
  * addresses. Protected by the hash_lock.
  */
-#define MAX_STACK_TRACE_ENTRIES	524288UL
-#define STACK_TRACE_HASH_SIZE	16384
+#define MAX_STACK_TRACE_ENTRIES	(1UL << CONFIG_LOCKDEP_STACK_TRACE_BITS)
+#define STACK_TRACE_HASH_SIZE	(1 << CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS)
 #endif
 
 /*
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 3656fa8..ce796ca 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1307,6 +1307,46 @@ config LOCKDEP
 config LOCKDEP_SMALL
 	bool
 
+config LOCKDEP_BITS
+	int "Bitsize for MAX_LOCKDEP_ENTRIES"
+	depends on LOCKDEP && !LOCKDEP_SMALL
+	range 10 30
+	default 15
+	help
+	  Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message.
+
+config LOCKDEP_CHAINS_BITS
+	int "Bitsize for MAX_LOCKDEP_CHAINS"
+	depends on LOCKDEP && !LOCKDEP_SMALL
+	range 10 30
+	default 16
+	help
+	  Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message.
+
+config LOCKDEP_STACK_TRACE_BITS
+	int "Bitsize for MAX_STACK_TRACE_ENTRIES"
+	depends on LOCKDEP && !LOCKDEP_SMALL
+	range 10 30
+	default 19
+	help
+	  Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message.
+
+config LOCKDEP_STACK_TRACE_HASH_BITS
+	int "Bitsize for STACK_TRACE_HASH_SIZE"
+	depends on LOCKDEP && !LOCKDEP_SMALL
+	range 10 30
+	default 14
+	help
+	  Try increasing this value if you need large MAX_STACK_TRACE_ENTRIES.
+
+config LOCKDEP_CIRCULAR_QUEUE_BITS
+	int "Bitsize for elements in circular_queue struct"
+	depends on LOCKDEP
+	range 10 30
+	default 12
+	help
+	  Try increasing this value if you hit "lockdep bfs error:-1" warning due to __cq_enqueue() failure.
+
 config DEBUG_LOCKDEP
 	bool "Lock dependency engine debugging"
 	depends on DEBUG_KERNEL && LOCKDEP
-- 
2.7.4

Re: [PATCH 5.10 0/1] Backport support for tracing capacity constants

[Greg Kroah-Hartman]

On Fri, Aug 12, 2022 at 01:08:02AM +0300, Alexey Khoroshilov wrote:
> Syzkaller reports a number of "BUG: MAX_LOCKDEP_CHAINS too low!" warnings
> on 5.10 branch and it means that the fuzz testing is terminated prematurely.
> Since upstream patch that allows to increase limits is applied cleanly
> and our testing demonstrated that it works well, we suggest to backport
> it to the 5.10 branch.

What about all of the newer kernels branches, it is needed in 5.15.y,
5.18.y and 5.19.y, right?  What's so special about 5.10.y?

thanks,

greg k-h

Re: [PATCH 5.10 0/1] Backport support for tracing capacity constants

[Alexey Khoroshilov]

On 12.08.2022 18:37, Greg Kroah-Hartman wrote:
> On Fri, Aug 12, 2022 at 01:08:02AM +0300, Alexey Khoroshilov wrote:
>> Syzkaller reports a number of "BUG: MAX_LOCKDEP_CHAINS too low!" warnings
>> on 5.10 branch and it means that the fuzz testing is terminated prematurely.
>> Since upstream patch that allows to increase limits is applied cleanly
>> and our testing demonstrated that it works well, we suggest to backport
>> it to the 5.10 branch.
> 
> What about all of the newer kernels branches, it is needed in 5.15.y,
> 5.18.y and 5.19.y, right?  What's so special about 5.10.y?


The commit was introduced in 5.13, so it is already there.

By the way, I messed up upstream commit id in my message, sorry about that.

The correct one:
5dc33592e95534dc8455ce3e9baaaf3dae0fff82

Thank you,
Alexey

Re: [PATCH 5.10 0/1] Backport support for tracing capacity constants

[Greg Kroah-Hartman]

On Fri, Aug 12, 2022 at 07:01:55PM +0300, Alexey Khoroshilov wrote:
> On 12.08.2022 18:37, Greg Kroah-Hartman wrote:
> > On Fri, Aug 12, 2022 at 01:08:02AM +0300, Alexey Khoroshilov wrote:
> >> Syzkaller reports a number of "BUG: MAX_LOCKDEP_CHAINS too low!" warnings
> >> on 5.10 branch and it means that the fuzz testing is terminated prematurely.
> >> Since upstream patch that allows to increase limits is applied cleanly
> >> and our testing demonstrated that it works well, we suggest to backport
> >> it to the 5.10 branch.
> > 
> > What about all of the newer kernels branches, it is needed in 5.15.y,
> > 5.18.y and 5.19.y, right?  What's so special about 5.10.y?
> 
> 
> The commit was introduced in 5.13, so it is already there.
> 
> By the way, I messed up upstream commit id in my message, sorry about that.
> 
> The correct one:
> 5dc33592e95534dc8455ce3e9baaaf3dae0fff82

Ah, that makes more sense, the id you gave me was not in a released
kernel yet...