[PATCH net-next 0/2] net/sched: don't wait for RCU when destroying qdisc lockdep keys
From: Vlad Poenaru
Date: Mon Oct 19 2026 - 16:15:54 EST
From: Vlad Poenaru <thevlad@xxxxxxxx>
On kernels with CONFIG_PROVE_LOCKING, every qdisc except ingress, clsact
and noqueue has a dynamic lockdep key, and destroying the qdisc calls
lockdep_unregister_key(), which waits for an expedited RCU grace period.
Replacing an mq root destroys one qdisc per TX queue under RTNL, so a
single "tc qdisc replace dev eth0 root mq" waits for that many grace
periods. Commit 7a3cedafccf8 ("lockdep: Speed up lockdep_unregister_key()
with expedited RCU synchronization") made each wait shorter as a
temporary workaround until hazard pointers are available.
The wait is redundant for qdiscs: the qdisc is freed with call_rcu()
after its key is unregistered, so the key's memory already outlives an
RCU grace period. Patch 1 revives Bart Van Assche's
lockdep_unregister_key_nosync() [1], with the grace-period requirement
spelled out, and patch 2 uses it for qdisc keys, as Eric suggested [2].
Boqun was concerned that a nosync variant is hard to enforce and review,
since a later refactor could move the free [3]. For qdiscs the RCU-deferred
free is not optional: datapath readers find the qdisc under RCU, so
freeing it synchronously would already be a use-after-free regardless of
lockdep. Patch 2 also documents the requirement at qdisc_lock_uninit().
The hazptr-based replacement for the wait is still under discussion [4];
if it lands, the nosync variant can stay as the no-wait path or be
dropped.
On an x86_64 KASAN + PROVE_LOCKING kernel (64 vCPU KVM guest, 64-queue
netdevsim device, 214K lock chains) this removes 5.3 ms of grace-period
wait from each of the 65 qdisc destroys in "tc qdisc replace dev eth0
root handle 1: mq".
A separate lockdep patch, sent to tip, makes the zap_class() part of
lockdep_unregister_key() cheaper [5]; the two are independent. Nilay
Shroff's pending "lockdep: Fix subclass resource leak in
lockdep_unregister_key()" [6] touches the same function as patch 1;
whichever lands second needs a trivial rebase.
Peter, Boqun, Waiman: if patch 1 looks fine, an Ack for taking it
through net-next with its user would be appreciated.
[1] https://lore.kernel.org/all/20250203175939.3133477-2-bvanassche@xxxxxxx/
[2] https://lore.kernel.org/all/CANn89iLvu_ijSV+FnrZ6qei_Ty2c9V-RjwLMk24+oOS91bNjaQ@xxxxxxxxxxxxxx/
[3] https://lore.kernel.org/all/Z-OPya5HoqbKmMGj@xxxxxxxx/
[4] https://lore.kernel.org/all/20261005171529.1378809-9-kunwu.chan@xxxxxxxxx/
[5] https://lore.kernel.org/all/20261019170018.699298-1-vlad.wing@xxxxxxxxx/
[6] https://lore.kernel.org/all/20260727182312.3750145-1-nilay@xxxxxxxxxxxxx/
Bart Van Assche (1):
lockdep: Introduce lockdep_unregister_key_nosync()
Vlad Poenaru (1):
net/sched: Don't wait for RCU when unregistering the qdisc lockdep key
include/linux/lockdep.h | 5 +++++
include/net/pkt_sched.h | 3 ++-
kernel/locking/lockdep.c | 36 +++++++++++++++++++++++++-----------
net/sched/sch_generic.c | 2 +-
4 files changed, 33 insertions(+), 13 deletions(-)
--
2.53.0-Meta