Re: BUG: MAX_LOCKDEP_ENTRIES too low! triggered by ext4&workqueue

["tj@kernel.org" <tj@kernel.org>]

On Wed, Mar 13, 2024 at 12:15:24PM +0000, Weiß, Simone wrote:
> Dear all,
> 
> For some experimentation, I have been running fuzzing campaigns and I
> noticed  BUG: MAX_LOCKDEP_ENTRIES too low! most likely triggered by ext4
> operations.
> 
> As I found a C reproducer in my setup, it could be bisected being introduced
> with the following:
> commit 967b494e2fd143a9c1a3201422aceadb5fa9fbfc
> Author: Tejun Heo <tj@kernel.org>
> Date:   Mon Aug 7 15:57:23 2023 -1000
> 
>     workqueue: Use a kthread_worker to release pool_workqueues
>     
>     pool_workqueue release path is currently bounced to system_wq; however, this
>     is a bit tricky because this bouncing occurs while holding a pool lock and
>     thus has risk of causing a A-A deadlock. This is currently addressed by the
>     fact that only unbound workqueues use this bouncing path and system_wq is a
>     per-cpu workqueue.
>  
> ...
> 
> It was reproducible on v6.6.16 and v6.16.21.
> The C reproducer is automatically generated by syzkaller and included below.
> 
> If you need any further information, just let me know.

Does the following happen to fix the issue for you?

Thanks.

diff --git a/kernel/locking/lockdep_internals.h b/kernel/locking/lockdep_internals.h
index bbe9000260d0..bc027ea2372b 100644
--- a/kernel/locking/lockdep_internals.h
+++ b/kernel/locking/lockdep_internals.h
@@ -94,7 +94,7 @@ static const unsigned long LOCKF_USED_IN_IRQ_READ =
  * table (if it's not there yet), and we check it for lock order
  * conflicts and deadlocks.
  */
-#define MAX_LOCKDEP_ENTRIES    16384UL
+#define MAX_LOCKDEP_ENTRIES    32768UL
 #define MAX_LOCKDEP_CHAINS_BITS        15
 #define MAX_STACK_TRACE_ENTRIES        262144UL
 #define STACK_TRACE_HASH_SIZE  8192

-- 
tejun