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 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.

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()
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