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
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=3d97ba93fb3566000c1c59691ea427370d33ea1... [2] https://syzkaller.appspot.com/bug?id=381cb436fe60dc03d7fd2a092b46d7f09542a72... [3] https://syzkaller.appspot.com/bug?id=a588183ac34c1437fc0785e8f220e88282e5a29... [4] https://lkml.kernel.org/r/4b8f7a57-fa20-47bd-48a0-ae35d860f233@i-love.sakura... [5] https://lkml.kernel.org/r/1c351187-253b-2d49-acaf-4563c63ae7d2@i-love.sakura...
References: https://lkml.kernel.org/r/1595640639-9310-1-git-send-email-penguin-kernel@I-... 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
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
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
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...
linux-stable-mirror@lists.linaro.org
-
Alexey Khoroshilov -
Greg Kroah-Hartman