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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20260115051221.68054-1-fushuai.wang@linux.dev>
Date: Thu, 15 Jan 2026 13:12:21 +0800
From: Fushuai Wang <fushuai.wang@...ux.dev>
To: kuba@...nel.org
Cc: Jason@...c4.com,
	andrew+netdev@...n.ch,
	davem@...emloft.net,
	edumazet@...gle.com,
	fushuai.wang@...ux.dev,
	linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org,
	pabeni@...hat.com,
	vadim.fedorenko@...ux.dev,
	wangfushuai@...du.com,
	wireguard@...ts.zx2c4.com
Subject: Re: [PATCH net-next v3] wireguard: allowedips: Use kfree_rcu() instead of call_rcu()

>> @@ -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.

---
Regards,
WANG