[BUG] lockdep: MAX_LOCKDEP_KEYS too low when destroying workqueues

[BUG] lockdep: MAX_LOCKDEP_KEYS too low when destroying workqueues

[许东洁]

Hello,

I found a lockdep issue using syzkaller where repeatedly destroying workqueues exhausts 
MAX_LOCKDEP_KEYS and disables the lock validator.

The bug triggers through:
nci_unregister_device -> destroy_workqueue -> drain_workqueue -> touch_wq_lockdep_map

Kernel output:
BUG: MAX_LOCKOCKDEP_KEYS too low!
turning off the locking correctness validator.

It appears workqueue lock classes are not properly released in destroy_workqueue, 
causing lock class leakage.

Config file: https://github.com/j1akai/KConfigFuzz_bug/blob/main/x86/mainline-config
Additional fuzzing context(report file, reproduce file, etc.):https://github.com/PLASSICAxu/OS-bug/tree/main/lockdep

Acknowledgments
Xu Dongjie
University of Chinese Academy of Sciences

Re: [BUG] lockdep: MAX_LOCKDEP_KEYS too low when destroying workqueues

[Heo]

On Sun, Nov 30, 2025 at 05:03:53PM +0800, 许东洁 wrote:
> Hello,
> 
> I found a lockdep issue using syzkaller where repeatedly destroying workqueues exhausts 
> MAX_LOCKDEP_KEYS and disables the lock validator.
> 
> The bug triggers through:
> nci_unregister_device -> destroy_workqueue -> drain_workqueue -> touch_wq_lockdep_map
> 
> Kernel output:
> BUG: MAX_LOCKOCKDEP_KEYS too low!
> turning off the locking correctness validator.
> 
> It appears workqueue lock classes are not properly released in destroy_workqueue, 
> causing lock class leakage.

Looks like the repro ends up creating and destroying workqueues back to
back. Part of workqueue destruction is asynchronous, so if you do that
quickly enough, running out of lockdep keys isn't that surprising. I'm not
sure this is a meaningful bug report.

Thanks.

-- 
tejun