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

[Vlad Poenaru <vlad.wing@gmail.com>]

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.

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.

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

Thanks,
Vlad