Re: [PATCH net-next v3] wireguard: allowedips: Use kfree_rcu() instead of call_rcu()
"Jason A. Donenfeld" <[email protected]> Thu, 15 Jan 2026 15:33:42 +0100
| Newsgroups | com.zx2c4.lists.wireguard,org.kernel.vger.linux-kernel,org.kernel.vger.netdev |
|---|---|
| Message-ID | <CAHmME9quqMVzD5zSEKvOFOYj3QLANAo2iYeqWQ1toV0C7gJXTg@mail.gmail.com> |
Hi Eric, On Thu, Jan 15, 2026 at 10:15 AM Eric Dumazet <[email protected]> wrote: > > > The existing cleanup path is: > > > wg_allowedips_slab_uninit() -> rcu_barrier() -> kmem_cache_destroy() > > > > > > With kfree_rcu(), this sequence could destroy the slab cache while > > > kfree_rcu_work() still has pending frees queued. The proper barrier for > > > kfree_rcu() is kvfree_rcu_barrier() which also calls flush_rcu_work() > > > on all pending batches. > > > > We do not need to add an explict kvfree_rcu_barrier(), becasue the commit > > 6c6c47b063b5 ("mm, slab: call kvfree_rcu_barrier() from kmem_cache_destroy()") > > already does it. > > It was doing it, but got replaced recently with a plain rcu_barrier() > > commit 0f35040de59371ad542b915d7b91176c9910dadc > Author: Harry Yoo <[email protected]> > Date: Mon Dec 8 00:41:47 2025 +0900 > > mm/slab: introduce kvfree_rcu_barrier_on_cache() for cache destruction > > We would like explicit +2 from mm _and_ rcu experts on this wireguard patch. I'll take this through the wireguard tree. But just a question on your comment, "It was doing it, but got replaced recently with a plain rcu_barrier()". Are you suggesting I need a kvfree_rcu_barrier() instead? The latest net-next has a kvfree_rcu_barrier_on_cache() called from kmem_cache_destroy() still... But are you suggesting I add this anyway? diff --git a/drivers/net/wireguard/allowedips.c b/drivers/net/wireguard/allowedips.c index 5ece9acad64d..aee39a0303b0 100644 --- a/drivers/net/wireguard/allowedips.c +++ b/drivers/net/wireguard/allowedips.c @@ -417,7 +417,7 @@ int __init wg_allowedips_slab_init(void) void wg_allowedips_slab_uninit(void) { - rcu_barrier(); + kvfree_rcu_barrier(); kmem_cache_destroy(node_cache); } Let me know. Thanks, Jason