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

[Boqun Feng <boqun@kernel.org>]

On Tue, Oct 20, 2026 at 05:53:35AM -0700, Vlad Poenaru wrote:
> On Mon, Oct 19, 2026 at 12:20:02PM -0700, Boqun Feng wrote:
> > I think my concern is still valid: for lockdep PoV,
> > lockdep_unregister_key_nosync() is an API that users have to use it
> > carefully, because it leaves the unregistration process in a stage that
> > you need to guarantee that the lockdep key reclamation is delayed by an
> > RCU grace period. Or in other words, do you have a way to prevent a user
> > from doing lockdep_unregister_key_nosync() but kfree(key), or some sort
> > of debugging to find a mis-use?
> 
> Not in this version, but lockdep could catch it. Every slab, page and
> vmalloc free already goes through debug_check_no_locks_freed(), so:
> 
>  - lockdep_unregister_key_nosync() records the key together with
>    get_state_synchronize_rcu() in a small fixed-size table;
>  - debug_check_no_locks_freed() warns if the freed range contains a
>    recorded key whose grace period has not elapsed yet
>    (poll_state_synchronize_rcu()), and retires entries whose grace
>    period has;
>  - lockdep_register_key() warns the same way if a recorded key is
>    reused too early.
> 
> The table is empty nearly all the time, so frees only pay for it during
> bursts of unregisters. A correct kfree_rcu() or call_rcu() free runs
> after the grace period and never warns; lockdep_unregister_key_nosync()
> followed by kfree() warns on that kfree().
> 
> Would that address your concern? If so I'll add it to v2.
> 

Sounds like a solid plan to me. You can make it behind
CONFIG_LOCKDEP_DEBUG.

> The other way would be for lockdep to keep the dynamic-key hash nodes in
> its own storage, freed via RCU like zapped classes, so is_dynamic_key()

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!

Regards,
Boqun

> never dereferences caller memory and lockdep_unregister_key() needs no
> wait at all. That removes the nosync API, but it is a bigger change.
> 
> Separately, two corrections to the cover letter: please ignore the
> stray "From: Vlad Poenaru <thevlad@meta.com>" line (Eric, sorry for the
> confusion; the series is from and signed off by vlad.wing@gmail.com),
> and [5] should be:
> 
> [5] https://lore.kernel.org/all/20261019170601.805087-1-vlad.wing@gmail.com/
> 
> Thanks,
> Vlad