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: <CAGudoHGbYvSAq=eJySxsf-AqkQ+ne_1gzuaojidA-GH+znw2hw@mail.gmail.com>
Date: Tue, 2 Dec 2025 06:10:36 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Al Viro <viro@...iv.linux.org.uk>
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 Tue, Dec 2, 2025 at 3:31 AM Al Viro <viro@...iv.linux.org.uk> wrote:
>         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.

So IIUC whatever APIs aside, the crux of this idea is to have
kmem_cache objs defined instead of having pointers to them, as in:
-struct kmem_cache *names_cachep __ro_after_init;
+struct kmem_cache names_cachep __ro_after_init;

I thought about doing it that way prior to runtime const machinery,
but given that said machinery exists I don't know if that's
justifiable.

To elaborate, while it apparently was created as a hack and does not
work for modules, it does not have to be that way and I would argue it
should be patched up to a fully-fleshed out solution.

Everything marked __ro_after_init is eligible for being patched up to
avoid being accessed, including numerous kmem caches.

Apart from those an example frequently read var is
percpu_counter_batch, which for vfs comes into play very time a new
file obj is allocated. The thing is also used by some of the
filesystems.

So if one was to pretend for a minute runtime-const *does* work for
modules and there are no header mess issues and usage is popping up
everywhere, is there a reason to handle kmem differently?

Both with your idea and the runtime thing extra changes would be
needed. in your case the thing at hand is no longer a pointer and all
consumers of a given cache need to get adjusted. If instead one went
the runtime route, some macros could be added for syntactic sugar to
provide the relevant accessor + init, which should be very easy to do
by wrapping existing code.

So I would vote against your idea, but it's the call of the mm folk.