Re: [PATCH net-next v3] wireguard: allowedips: Use kfree_rcu() instead of call_rcu()

From: Jason A. Donenfeld

Date: Thu Jan 15 2026 - 09:33:52 EST


Hi Eric,

On Thu, Jan 15, 2026 at 10:15 AM Eric Dumazet <edumazet@xxxxxxxxxx> 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 <harry.yoo@xxxxxxxxxx>
> 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