linux-kernel - Re: [PATCH v2] fs: hide names_cache behind runtime const machinery

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: <20251202023147.GA1712166@ZenIV>
Date: Tue, 2 Dec 2025 02:31:47 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: brauner@...nel.org, jack@...e.cz, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2] fs: hide names_cache behind runtime const machinery

On Mon, Dec 01, 2025 at 08:51:17AM +0000, Al Viro wrote:
> On Mon, Dec 01, 2025 at 09:32:26AM +0100, Mateusz Guzik wrote:
> > s/names_cachep/names_cache/ for consistency with dentry cache.
> > 
> > Signed-off-by: Mateusz Guzik <mjguzik@...il.com>
> > ---
> > 
> > v2:
> > - rebased on top of work.filename-refcnt
> > 
> > ACHTUNG: there is a change queued for 6.19 merge window which treats
> > dentry cache the same way:
> > commit 21b561dab1406e63740ebe240c7b69f19e1bcf58
> > Author: Mateusz Guzik <mjguzik@...il.com>
> > Date:   Wed Nov 5 16:36:22 2025 +0100
> > 
> >     fs: hide dentry_cache behind runtime const machinery
> > 
> > which would result in a merge conflict in vmlinux.lds.h. thus I
> > cherry-picked before generating the diff to avoid the issue for later.
> 
> *shrug*
> For now I'm working on top of v6.18; rebase to -rc1 will happen at the
> end of window...
> 
> Anyway, not a problem; applied with obvious massage.  Will push tomorrow
> once I sort the linearization out.

	FWIW, I wonder if we would be better off with the following trick:
add
	struct kmem_cache *preallocated;
to struct kmem_cache_args.  Semantics: if the value is non-NULL, it must
point to an unitialized object of type struct kmem_cache; in that case
__kmem_cache_create_args() will use that object (and return its address
on success) instead of allocating one from kmem_cache.  kmem_cache_destroy()
should not be called for it.

It's very easy to do, AFAICS:
	1) non-NULL => have __kmem_cache_create_args() skip the __kmem_cache_alias()
path.
	2) non-NULL => have create_cache() zero what it points to and use that pointer
instead of calling kmem_cache_zalloc()
	3) non-NULL => skip kmem_cache_free() at create_cache() out_free_cache:

"Don't do kmem_cache_destroy() to those" might or might not be worth relaxing -
I hadn't looked into the lifetime issues for kmem_cache instances, no idea
how painful would that be; for core kernel caches it's not an issue, obviously.
For modules it is, but then runtime_constant machinery is not an option there
either.