Re: [PATCH net-next 0/2] net/sched: don't wait for RCU when destroying qdisc lockdep keys

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

On Tue, Oct 20, 2026 at 10:15:47AM -0700, Boqun Feng wrote:
> Sounds like a solid plan to me. You can make it behind
> CONFIG_LOCKDEP_DEBUG.

Done, under CONFIG_DEBUG_LOCKDEP, as a fallback.

> But this means lockdep needs to do its own allocation for the hash
> nodes? Where does the memory come from, a slab or something? If so, I
> think we should probably avoid that. But I like this idea more since it
> won't introduce another API. So please do explore this idea as well,
> thank you!

No slab. The nodes live in a static array with an in-use bitmap, like
lockdep's classes, list entries and chains, sized by a new
CONFIG_LOCKDEP_DYNAMIC_KEYS_BITS. Unregistering hands the node to the
existing delayed_free machinery, so a slot is only reused after a grace
period, and lockdep_unregister_key() no longer waits at all.
is_dynamic_key() only compares key addresses stored in lockdep's own
memory. I posted it as an RFC against tip/locking/core:

https://lore.kernel.org/all/20261021115621.3194947-1-vlad.wing@gmail.com/

With that, this series is not needed. Given Jakub's note it is on hold
anyway; I will only come back to it if the RFC approach does not work
out.

Thanks,
Vlad