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: Mon, 17 Jun 2024 23:08:58 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Uladzislau Rezki <urezki@...il.com>
Cc: 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?

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

> I am asking because inventing a new kfree_rcu_barrier() might not be so
> straight forward.

Agreed.

> 
> --
> Uladzislau Rezki