Messages in this thread Patch in this message | | | Date | Wed, 13 Mar 2024 10:09:57 -1000 | From | "" <> | Subject | Re: BUG: MAX_LOCKDEP_ENTRIES too low! triggered by ext4&workqueue |
| |
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
| |