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

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

On Mon, Oct 26, 2026 at 07:07:39AM -0700, Boqun Feng wrote: > 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.

I went through all the callers (36 call sites). Mostly yes, with a few
exceptions: ath11k/ath12k register a key for every SRNG ring id (170-210
per device) but only initialize the rings they set up, hugetlb_cgroup
initializes when the cgroup file is created, and omap_hwmod, ucsi and
jbd2 skip the init on error paths. (omap_hwmod also frees a registered
key without unregistering it on one allocation failure; I'll send a
separate fix.)

The init itself doesn't take a class: every caller uses subclass 0, so
the class only appears on the first acquire. That matters for qdiscs. mq
creates a child for every TX queue, up to 4096 per device, each with its
own key, and a child's q.lock isn't taken until the device is
deactivated (or, for qdisc kinds that take it on transmit, until there
is traffic). In a VM with this RFC, four dummy devices with numtxqueues
4096 and an mq root, left down, went from 214 to 16384 dynamic keys
while the classes stayed under 900, and the pool ran out.

The class table is already exposed the same way, though. Deactivating a
device takes the q.lock of every TX queue's qdisc in
some_qdisc_is_busy(), so on current tip two such devices taken up and
down went from 852 to 8192 classes and hit "BUG: MAX_LOCKDEP_KEYS too
low!". (I ran both as root; from the code, the same commands should only
need CAP_NET_ADMIN in a user namespace.) So the cap adds another way to
reach a limit the same user can already reach. Agreed on dropping (1),
and I'll go with your suggestion:
MAX_LOCKDEP_DYNAMIC_KEYS = 2 * MAX_LOCKDEP_KEYS, no Kconfig. That is
16K, the same as the RFC's current default. Should LOCKDEP_SMALL keep a
smaller value? 16K nodes are ~384KB of bss on sparc64.

If the qdisc case should be narrowed anyway, net/sched could skip the
key for pfifo_fast, the only qdisc with TCQ_F_NOLOCK in its
static_flags, as it already does for ingress, clsact and noqueue. It
takes q.lock only around its requeue lists (gso_skb, skb_bad_txq) and in
control paths, never across a nested transmit, so I don't think that
brings back the mirred false positive from af0cb3fa3f9e, but netdev
would have to agree. It wouldn't bound the count either, since the user
picks the qdisc kind.

Does that work for you?

Thanks,
Vlad