* [PATCH net-next 0/2] net/sched: don't wait for RCU when destroying qdisc lockdep keys
@ 2026-10-19 17:02 Vlad Poenaru
2026-10-19 17:02 ` [PATCH net-next 1/2] lockdep: Introduce lockdep_unregister_key_nosync() Vlad Poenaru
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Vlad Poenaru @ 2026-10-19 17:02 UTC (permalink / raw)
To: netdev, Jamal Hadi Salim, Jiri Pirko, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
Bart Van Assche, Davide Caratti, Breno Leitao, Nilay Shroff,
linux-kernel, Vlad Poenaru
From: Vlad Poenaru <thevlad@meta.com>
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@acm.org/
[2] https://lore.kernel.org/all/CANn89iLvu_ijSV+FnrZ6qei_Ty2c9V-RjwLMk24+oOS91bNjaQ@mail.gmail.com/
[3] https://lore.kernel.org/all/Z-OPya5HoqbKmMGj@Mac.home/
[4] https://lore.kernel.org/all/20261005171529.1378809-9-kunwu.chan@gmail.com/
[5] https://lore.kernel.org/all/20261019170018.699298-1-vlad.wing@gmail.com/
[6] https://lore.kernel.org/all/20260727182312.3750145-1-nilay@linux.ibm.com/
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH net-next 1/2] lockdep: Introduce lockdep_unregister_key_nosync()
2026-10-19 17:02 [PATCH net-next 0/2] net/sched: don't wait for RCU when destroying qdisc lockdep keys Vlad Poenaru
@ 2026-10-19 17:02 ` Vlad Poenaru
2026-10-19 17:38 ` Eric Dumazet
2026-10-19 17:02 ` [PATCH net-next 2/2] net/sched: Don't wait for RCU when unregistering the qdisc lockdep key Vlad Poenaru
2026-10-19 19:20 ` [PATCH net-next 0/2] net/sched: don't wait for RCU when destroying qdisc lockdep keys Boqun Feng
2 siblings, 1 reply; 6+ messages in thread
From: Vlad Poenaru @ 2026-10-19 17:02 UTC (permalink / raw)
To: netdev, Jamal Hadi Salim, Jiri Pirko, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
Bart Van Assche, Davide Caratti, Breno Leitao, Nilay Shroff,
linux-kernel
From: Bart Van Assche <bvanassche@acm.org>
Add a variant of lockdep_unregister_key() that neither sleeps nor waits
for an RCU grace period. Instead the caller must make sure that a grace
period elapses after the call before the memory holding the key is
freed or reused.
That lets callers that already free the key's memory with call_rcu() or
kfree_rcu() avoid waiting for a second grace period. The qdisc code is
such a caller: all qdiscs except ingress, clsact and noqueue embed a
dynamic lockdep key and are freed with call_rcu(), and replacing an mq
root on a multi-queue NIC destroys one qdisc per TX queue under RTNL,
each currently waiting for its own expedited grace period.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Will Deacon <will@kernel.org>
Cc: Waiman Long <longman@redhat.com>
Cc: Boqun Feng <boqun@kernel.org>
Link: https://lore.kernel.org/all/20250203175939.3133477-2-bvanassche@acm.org/
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
[vlad: rebase onto synchronize_rcu_expedited(), spell out the grace
period requirement in the comments and changelog, describe the qdisc
use case]
Signed-off-by: Vlad Poenaru <vlad.wing@gmail.com>
---
include/linux/lockdep.h | 5 +++++
kernel/locking/lockdep.c | 36 +++++++++++++++++++++++++-----------
2 files changed, 30 insertions(+), 11 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index a6451ecbbe9a0..80b27973b7f72 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -117,6 +117,7 @@ do { \
} while (0)
extern void lockdep_register_key(struct lock_class_key *key);
+extern void lockdep_unregister_key_nosync(struct lock_class_key *key);
extern void lockdep_unregister_key(struct lock_class_key *key);
/*
@@ -375,6 +376,10 @@ static inline void lockdep_register_key(struct lock_class_key *key)
{
}
+static inline void lockdep_unregister_key_nosync(struct lock_class_key *key)
+{
+}
+
static inline void lockdep_unregister_key(struct lock_class_key *key)
{
}
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index c3dc84a7cef26..16c8480e282e3 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -6669,13 +6669,19 @@ void lockdep_reset_lock(struct lockdep_map *lock)
}
/*
- * Unregister a dynamically allocated key.
+ * Unregister a dynamically allocated key without waiting for RCU readers.
*
* Unlike lockdep_register_key(), a search is always done to find a matching
* key irrespective of debug_locks to avoid potential invalid access to freed
* memory in lock_class entry.
+ *
+ * is_dynamic_key() may still be walking past @key under RCU when this
+ * returns. The memory holding @key must not be freed or reused, including by
+ * registering @key again, until an RCU grace period that starts after this
+ * call has elapsed, e.g. by freeing it with call_rcu() or kfree_rcu() queued
+ * after this call. Does not sleep.
*/
-void lockdep_unregister_key(struct lock_class_key *key)
+void lockdep_unregister_key_nosync(struct lock_class_key *key)
{
struct hlist_head *hash_head = keyhashentry(key);
struct lock_class_key *k;
@@ -6684,8 +6690,6 @@ void lockdep_unregister_key(struct lock_class_key *key)
bool found = false;
bool need_callback = false;
- might_sleep();
-
if (WARN_ON_ONCE(static_obj(key)))
return;
@@ -6711,15 +6715,25 @@ void lockdep_unregister_key(struct lock_class_key *key)
if (need_callback)
call_rcu(&delayed_free.rcu_head, free_zapped_rcu);
+}
+EXPORT_SYMBOL_GPL(lockdep_unregister_key_nosync);
+
+/*
+ * Unregister a dynamically allocated key and wait for is_dynamic_key()
+ * readers, so that the memory holding @key may be freed as soon as this
+ * returns. May sleep.
+ */
+void lockdep_unregister_key(struct lock_class_key *key)
+{
+ might_sleep();
+
+ lockdep_unregister_key_nosync(key);
/*
- * Wait until is_dynamic_key() has finished accessing k->hash_entry.
- *
- * Some operations like __qdisc_destroy() will call this in a debug
- * kernel, and the network traffic is disabled while waiting, hence
- * the delay of the wait matters in debugging cases. Currently use a
- * synchronize_rcu_expedited() to speed up the wait at the cost of
- * system IPIs. TODO: Replace RCU with hazptr for this.
+ * Expedited to keep the wait short, at the cost of IPIs. Callers that
+ * free @key after a grace period anyway should use
+ * lockdep_unregister_key_nosync() instead.
+ * TODO: Replace RCU with hazptr for this.
*/
synchronize_rcu_expedited();
}
--
2.53.0-Meta
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH net-next 2/2] net/sched: Don't wait for RCU when unregistering the qdisc lockdep key
2026-10-19 17:02 [PATCH net-next 0/2] net/sched: don't wait for RCU when destroying qdisc lockdep keys Vlad Poenaru
2026-10-19 17:02 ` [PATCH net-next 1/2] lockdep: Introduce lockdep_unregister_key_nosync() Vlad Poenaru
@ 2026-10-19 17:02 ` Vlad Poenaru
2026-10-19 17:37 ` Eric Dumazet
2026-10-19 19:20 ` [PATCH net-next 0/2] net/sched: don't wait for RCU when destroying qdisc lockdep keys Boqun Feng
2 siblings, 1 reply; 6+ messages in thread
From: Vlad Poenaru @ 2026-10-19 17:02 UTC (permalink / raw)
To: netdev, Jamal Hadi Salim, Jiri Pirko, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
Bart Van Assche, Davide Caratti, Breno Leitao, Nilay Shroff,
linux-kernel, Eric Dumazet
Since commit af0cb3fa3f9e ("net/sched: fix false lockdep warning on
qdisc root lock") every qdisc except ingress, clsact and noqueue
registers a dynamic lockdep key, and destroying it 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, each of which IPIs every CPU that is not idle.
The wait is not needed here: __qdisc_destroy() and qdisc_create() free
the qdisc with qdisc_free_rcu() after unregistering, which already
keeps the key's memory valid for a grace period. Use
lockdep_unregister_key_nosync(), and free with kfree_rcu() in the one
qdisc_alloc() error path that used kfree().
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".
Suggested-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/all/CANn89iLvu_ijSV+FnrZ6qei_Ty2c9V-RjwLMk24+oOS91bNjaQ@mail.gmail.com/
Signed-off-by: Vlad Poenaru <vlad.wing@gmail.com>
---
include/net/pkt_sched.h | 3 ++-
net/sched/sch_generic.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h
index 90d3e7943b19a..1f4195dabaa57 100644
--- a/include/net/pkt_sched.h
+++ b/include/net/pkt_sched.h
@@ -323,6 +323,7 @@ static inline void qdisc_lock_init(struct Qdisc *sch,
lockdep_set_class(&sch->q.lock, &sch->root_lock_key);
}
+/* Free @sch only after an RCU grace period, e.g. with qdisc_free_rcu(). */
static inline void qdisc_lock_uninit(struct Qdisc *sch,
const struct Qdisc_ops *ops)
{
@@ -330,7 +331,7 @@ static inline void qdisc_lock_uninit(struct Qdisc *sch,
ops == &noqueue_qdisc_ops)
return;
- lockdep_unregister_key(&sch->root_lock_key);
+ lockdep_unregister_key_nosync(&sch->root_lock_key);
}
#endif
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index 6f6a6f0d5eb0d..28791d4fe35b1 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -1033,7 +1033,7 @@ struct Qdisc *qdisc_alloc(struct netdev_queue *dev_queue,
return sch;
errout1:
qdisc_lock_uninit(sch, ops);
- kfree(sch);
+ kfree_rcu(sch, rcu);
errout:
return ERR_PTR(err);
}
--
2.53.0-Meta
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH net-next 2/2] net/sched: Don't wait for RCU when unregistering the qdisc lockdep key
2026-10-19 17:02 ` [PATCH net-next 2/2] net/sched: Don't wait for RCU when unregistering the qdisc lockdep key Vlad Poenaru
@ 2026-10-19 17:37 ` Eric Dumazet
0 siblings, 0 replies; 6+ messages in thread
From: Eric Dumazet @ 2026-10-19 17:37 UTC (permalink / raw)
To: Vlad Poenaru
Cc: netdev, Jamal Hadi Salim, Jiri Pirko, David S. Miller,
Jakub Kicinski, Paolo Abeni, Simon Horman, Peter Zijlstra,
Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
Bart Van Assche, Davide Caratti, Breno Leitao, Nilay Shroff,
linux-kernel, Eric Dumazet
Le lun. 19 oct. 2026 à 19:02, Vlad Poenaru <vlad.wing@gmail.com> a écrit :
>
> Since commit af0cb3fa3f9e ("net/sched: fix false lockdep warning on
> qdisc root lock") every qdisc except ingress, clsact and noqueue
> registers a dynamic lockdep key, and destroying it 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, each of which IPIs every CPU that is not idle.
>
> The wait is not needed here: __qdisc_destroy() and qdisc_create() free
> the qdisc with qdisc_free_rcu() after unregistering, which already
> keeps the key's memory valid for a grace period. Use
> lockdep_unregister_key_nosync(), and free with kfree_rcu() in the one
> qdisc_alloc() error path that used kfree().
>
> 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".
>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Link: https://lore.kernel.org/all/CANn89iLvu_ijSV+FnrZ6qei_Ty2c9V-RjwLMk24+oOS91bNjaQ@mail.gmail.com/
> Signed-off-by: Vlad Poenaru <vlad.wing@gmail.com>
Note the cover letter has 'From: Vlad Poenaru <thevlad@meta.com>', so
this SoB is a bit confusing.
Reviewed-by: Eric Dumazet <edumazet@kernel.org>
Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net-next 1/2] lockdep: Introduce lockdep_unregister_key_nosync()
2026-10-19 17:02 ` [PATCH net-next 1/2] lockdep: Introduce lockdep_unregister_key_nosync() Vlad Poenaru
@ 2026-10-19 17:38 ` Eric Dumazet
0 siblings, 0 replies; 6+ messages in thread
From: Eric Dumazet @ 2026-10-19 17:38 UTC (permalink / raw)
To: Vlad Poenaru
Cc: netdev, Jamal Hadi Salim, Jiri Pirko, David S. Miller,
Jakub Kicinski, Paolo Abeni, Simon Horman, Peter Zijlstra,
Ingo Molnar, Will Deacon, Boqun Feng, Waiman Long,
Bart Van Assche, Davide Caratti, Breno Leitao, Nilay Shroff,
linux-kernel
Le lun. 19 oct. 2026 à 19:02, Vlad Poenaru <vlad.wing@gmail.com> a écrit :
>
> From: Bart Van Assche <bvanassche@acm.org>
>
> Add a variant of lockdep_unregister_key() that neither sleeps nor waits
> for an RCU grace period. Instead the caller must make sure that a grace
> period elapses after the call before the memory holding the key is
> freed or reused.
>
> That lets callers that already free the key's memory with call_rcu() or
> kfree_rcu() avoid waiting for a second grace period. The qdisc code is
> such a caller: all qdiscs except ingress, clsact and noqueue embed a
> dynamic lockdep key and are freed with call_rcu(), and replacing an mq
> root on a multi-queue NIC destroys one qdisc per TX queue under RTNL,
> each currently waiting for its own expedited grace period.
>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Waiman Long <longman@redhat.com>
> Cc: Boqun Feng <boqun@kernel.org>
> Link: https://lore.kernel.org/all/20250203175939.3133477-2-bvanassche@acm.org/
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> [vlad: rebase onto synchronize_rcu_expedited(), spell out the grace
> period requirement in the comments and changelog, describe the qdisc
> use case]
> Signed-off-by: Vlad Poenaru <vlad.wing@gmail.com>
Acked-by: Eric Dumazet <edumazet@kenel.org>
Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net-next 0/2] net/sched: don't wait for RCU when destroying qdisc lockdep keys
2026-10-19 17:02 [PATCH net-next 0/2] net/sched: don't wait for RCU when destroying qdisc lockdep keys Vlad Poenaru
2026-10-19 17:02 ` [PATCH net-next 1/2] lockdep: Introduce lockdep_unregister_key_nosync() Vlad Poenaru
2026-10-19 17:02 ` [PATCH net-next 2/2] net/sched: Don't wait for RCU when unregistering the qdisc lockdep key Vlad Poenaru
@ 2026-10-19 19:20 ` Boqun Feng
2 siblings, 0 replies; 6+ messages in thread
From: Boqun Feng @ 2026-10-19 19:20 UTC (permalink / raw)
To: Vlad Poenaru
Cc: netdev, Jamal Hadi Salim, Jiri Pirko, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long,
Bart Van Assche, Davide Caratti, Breno Leitao, Nilay Shroff,
linux-kernel, Vlad Poenaru
On Mon, Oct 19, 2026 at 10:02:23AM -0700, Vlad Poenaru wrote:
> From: Vlad Poenaru <thevlad@meta.com>
>
> 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().
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?
Regards,
Boqun
> 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@acm.org/
> [2] https://lore.kernel.org/all/CANn89iLvu_ijSV+FnrZ6qei_Ty2c9V-RjwLMk24+oOS91bNjaQ@mail.gmail.com/
> [3] https://lore.kernel.org/all/Z-OPya5HoqbKmMGj@Mac.home/
> [4] https://lore.kernel.org/all/20261005171529.1378809-9-kunwu.chan@gmail.com/
> [5] https://lore.kernel.org/all/20261019170018.699298-1-vlad.wing@gmail.com/
> [6] https://lore.kernel.org/all/20260727182312.3750145-1-nilay@linux.ibm.com/
>
> 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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-10-19 19:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-19 17:02 [PATCH net-next 0/2] net/sched: don't wait for RCU when destroying qdisc lockdep keys Vlad Poenaru
2026-10-19 17:02 ` [PATCH net-next 1/2] lockdep: Introduce lockdep_unregister_key_nosync() Vlad Poenaru
2026-10-19 17:38 ` Eric Dumazet
2026-10-19 17:02 ` [PATCH net-next 2/2] net/sched: Don't wait for RCU when unregistering the qdisc lockdep key Vlad Poenaru
2026-10-19 17:37 ` Eric Dumazet
2026-10-19 19:20 ` [PATCH net-next 0/2] net/sched: don't wait for RCU when destroying qdisc lockdep keys Boqun Feng
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox