linux-kernel - Re: [RFC PATCH 00/15] kmem_cache instances with static storage duration

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: <CAHk-=wiibHkNcsvsVpQLCMNJOh-dxEXNqXUxfQ63CTqX5w04Pg@mail.gmail.com>
Date: Fri, 9 Jan 2026 19:33:41 -1000
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: linux-mm@...ck.org, Vlastimil Babka <vbabka@...e.cz>, Harry Yoo <harry.yoo@...cle.com>, 
	linux-fsdevel@...r.kernel.org, Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, 
	Mateusz Guzik <mguzik@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 00/15] kmem_cache instances with static storage duration

On Fri, 9 Jan 2026 at 18:01, Al Viro <viro@...iv.linux.org.uk> wrote:
>
>         There's an alternative approach applicable at least to the caches
> that are never destroyed, which covers a lot of them.  No matter what,
> runtime_const for pointers is not going to be faster than plain &,
> so if we had struct kmem_cache instances with static storage duration, we
> would be at least no worse off than we are with runtime_const variants.

I like it. Much better than runtime_const for these things.

That said, I don't love the commit messages. "turn xyzzy
static-duration" reads very oddly to me, and because I saw the emails
out of order originally it just made me go "whaa?"

So can we please explain this some more obvious way. Maybe just "Make
xyz be statically allocated". Yes, I'm nitpicking, but I feel like
explaining core patches is worth the effort.

And maybe that's for the sad reason that I read more explanations than
code these days '/

                Linus