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] [day] [month] [year] [list]
Message-ID: <zkiaatyjqk4p445wi5wz5oztzxvcanp5lbnmt54pa3cmvqibi6@4r4e7evtclwe>
Date: Mon, 5 Aug 2024 13:24:49 +0200
From: Mateusz Guzik <mjguzik@...il.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Pedro Falcato <pedro.falcato@...il.com>, 
	Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>, 
	David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Roman Gushchin <roman.gushchin@...ux.dev>, 
	Hyeonggon Yoo <42.hyeyoo@...il.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] slab: Error out on duplicate cache names when DEBUG_VM=y

On Mon, Aug 05, 2024 at 12:38:29PM +0200, Vlastimil Babka wrote:
> What about module unload/reload with a SLAB_TYPESAFE_BY_RCU cache that will
> delay its freeing. Soon also if there are kfree_rcu()'s in flight. And the
> zombie cache can stay also permamently around if it fails to be destroy
> because some objects were not freed.
> 

It should be an invariant that the cache is fully whacked by the time
kmem_cache_destroy returns, at worst with the exception of when leaked
items are encountered (but even then it should be renamed to something
indicating it is defunct).

Suppose a cache could not have been destroyed and was left as is, then
the offending module was loaded again -- now you got two with the same
name, which is not that great either.

I find myself quite surprised that kmem_cache_destroy can return even if
cache destruction is still pending.

This was added in 657dc2f97220 ("slab: remove synchronous rcu_barrier()
call in memcg cache release path"), citing batching benefits for
frequent kmem cache creation/destruction.

I believe the very notion of doing that *frequently* is b0rked and any
code doing it should be patched to stop regardless.

Even so, if there are any benefits to the committed patch, it perhaps
can be augmented so that the kmem_cache_destroy caller can wait for the
entire thing to finish (e.g., with a completion).

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ