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

[Al Viro <viro@zeniv.linux.org.uk>]

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