linux-kernel - Re: [PATCH 00/14] replace call_rcu by kfree_rcu for simple kmem_cache

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]

Date: Tue, 18 Jun 2024 11:31:00 +0200
From: Uladzislau Rezki <urezki@...il.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Uladzislau Rezki <urezki@...il.com>, paulmck@...nel.org,
	"Jason A. Donenfeld" <Jason@...c4.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Julia Lawall <Julia.Lawall@...ia.fr>, linux-block@...r.kernel.org,
	kernel-janitors@...r.kernel.org, bridge@...ts.linux.dev,
	linux-trace-kernel@...r.kernel.org,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	kvm@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
	"Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
	Christophe Leroy <christophe.leroy@...roup.eu>,
	Nicholas Piggin <npiggin@...il.com>, netdev@...r.kernel.org,
	wireguard@...ts.zx2c4.com, linux-kernel@...r.kernel.org,
	ecryptfs@...r.kernel.org, Neil Brown <neilb@...e.de>,
	Olga Kornievskaia <kolga@...app.com>, Dai Ngo <Dai.Ngo@...cle.com>,
	Tom Talpey <tom@...pey.com>, linux-nfs@...r.kernel.org,
	linux-can@...r.kernel.org, Lai Jiangshan <jiangshanlai@...il.com>,
	netfilter-devel@...r.kernel.org, coreteam@...filter.org,
	kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: [PATCH 00/14] replace call_rcu by kfree_rcu for simple
 kmem_cache_free callback

> On 6/17/24 8:42 PM, Uladzislau Rezki wrote:
> >> +
> >> +	s = container_of(work, struct kmem_cache, async_destroy_work);
> >> +
> >> +	// XXX use the real kmem_cache_free_barrier() or similar thing here
> > It implies that we need to introduce kfree_rcu_barrier(), a new API, which i
> > wanted to avoid initially.
> 
> I wanted to avoid new API or flags for kfree_rcu() users and this would
> be achieved. The barrier is used internally so I don't consider that an
> API to avoid. How difficult is the implementation is another question,
> depending on how the current batching works. Once (if) we have sheaves
> proven to work and move kfree_rcu() fully into SLUB, the barrier might
> also look different and hopefully easier. So maybe it's not worth to
> invest too much into that barrier and just go for the potentially
> longer, but easier to implement?
> 
Right. I agree here. If the cache is not empty, OK, we just defer the
work, even we can use a big 21 seconds delay, after that we just "warn"
if it is still not empty and leave it as it is, i.e. emit a warning and
we are done.

Destroying the cache is not something that must happen right away. 

> > Since you do it asynchronous can we just repeat
> > and wait until it a cache is furry freed?
> 
> The problem is we want to detect the cases when it's not fully freed
> because there was an actual read. So at some point we'd need to stop the
> repeats because we know there can no longer be any kfree_rcu()'s in
> flight since the kmem_cache_destroy() was called.
> 
Agree. As noted above, we can go with 21 seconds(as an example) interval
and just perform destroy(without repeating).

--
Uladzislau Rezki