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: <aWdB90WCfsArtwOw@hyeyoo>
Date: Wed, 14 Jan 2026 16:12:55 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, linux-mm@...ck.org,
        Vlastimil Babka <vbabka@...e.cz>, 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 Sat, Jan 10, 2026 at 06:16:00AM +0000, Al Viro wrote:
> On Fri, Jan 09, 2026 at 07:33:41PM -1000, Linus Torvalds wrote:
> > 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.
> 
> Point, but TBH the tail of the series is basically a demo for conversions
> as well as "this is what I'd been testing, FSVO".  In non-RFC form these
> would be folded into fewer commits, if nothing else...
> 
> I'd really like to hear comments on the first two commits from SLAB
> maintainers - for example, if slab_flags_t bits are considered a scarce
> resource, the second commit would need to be modified.  Still doable, but

I think it's okay to introduce a new cache flag as long as it's simpler.
IMHO it's not a scarce resource (yet).

> representation would be more convoluted...
> 
> Another question is whether it's worth checking for accidental call
> of e.g. kmem_cache_setup() on an already initialized cache, statically
> or dynamically allocated.

No strong opinion from me.

> Again, up to maintainers - their subsystem,
> their preferences.

-- 
Cheers,
Harry / Hyeonggon