Re: [RFC PATCH] lockdep: Keep dynamic key hash nodes in lockdep-owned storage

[Boqun Feng]

On Fri, Oct 23, 2026 at 05:19:46AM -0700, Vlad Poenaru wrote:
> On 10/21/26 8:01 PM, Bart Van Assche wrote:
> > This patch introduces a new hard upper limit on the number of dynamic
> > lockdep keys. That's unfortunate but I assume it's not possible to
> > eliminate this hard upper bound if the key storage is owned by
> > lockdep?
> 
> It isn't inherent; it comes from preallocating the nodes the way lockdep
> does for its other tables. Two ways to lift it:
> 
> 1. Fall back to the embedded node when the pool is full. Keys
>    registered after that are linked through their own hash_entry, as
>    today, and only those wait for a grace period when they are
>    unregistered. The key stays at 16 bytes and there is a second lookup
>    path, but running out becomes a slowdown instead of lockdep turning
>    itself off.
> 

This gives me feeling that we did something for nothing, because in a
system where there are a plenty of dynamic keys, we back to the current
status after we introduce another hashlist.

> 2. Grow the pool in chunks allocated outside the graph lock in
>    lockdep_register_key(). That removes the bound without a fallback,
>    but it is the allocation Boqun preferred to avoid.
> 
> For what it's worth, keys whose locks are ever taken already count
> against MAX_LOCKDEP_KEYS (8K classes), and the default pool is 16K, so
> what the cap adds is a limit on keys that never get a class.
> 

Yeah, I think if everyone call lockdep_init_map_type() right after
lockdep_register_key(), MAX_LOCKDEP_KEYS will be reached to the limit
before MAX_LOCKDEP_DYNAMIC_KEYS. So technically it's not a new
limitation. Honestly you can just make MAX_LOCKDEP_DYNAMIC_KEYS = 2 *
MAX_LOCKDEP_KEYS (i.e. without introducing a Kconfig), "2 *" is needed
because a key can be in-between lockdep_register_key() and
lockdep_init_map_type() and pending_free can be delayed, so "2 *"
provides a buffer for when active key numbers > class numbers.

It might be worth checking whether a lockdep_register_key() is always
followed by a some sort of lockdep_init_map_type() in the kernel code
base.

Regards,
Boqun


> Boqun, would you prefer (1), so that the cap can never turn lockdep off?
> 
> Thanks,
> Vlad