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: <36c60acd-543e-48c5-8bd2-6ed509972d28@suse.cz>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ