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

On Thu, Jan 15, 2026 at 6:12 AM Fushuai Wang <[email protected]> wrote:
>
> >> @@ -271,13 +266,13 @@ static void remove_node(struct allowedips_node *node, struct mutex *lock)
> >>      if (free_parent)
> >>              child = rcu_dereference_protected(parent->bit[!(node->parent_bit_packed & 1)],
> >>                                                lockdep_is_held(lock));
> >> -    call_rcu(&node->rcu, node_free_rcu);
> >> +    kfree_rcu(node, rcu);
> >
> > Does wg_allowedips_slab_uninit() need to be updated to use
> > kvfree_rcu_barrier() instead of rcu_barrier()?
> >
> > When CONFIG_KVFREE_RCU_BATCHED is enabled (the default), kfree_rcu()
> > uses a batched mechanism that queues work via queue_rcu_work(). The
> > rcu_barrier() call waits for RCU callbacks to complete, but these
> > callbacks only queue the actual free to a workqueue via rcu_work_rcufn().
> > The workqueue work that calls kvfree() may still be pending after
> > rcu_barrier() returns.
> >
> > 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.

Thank you.