linux-kernel - Re: [PATCH v5 2/4] slab: Introduce kmalloc

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wh7jG7vUqY2JjkJmjxOYzXR+iUARN6W908pCVfmyprSvg@mail.gmail.com>
Date: Mon, 24 Nov 2025 17:25:25 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <kees@...nel.org>
Cc: Vlastimil Babka <vbabka@...e.cz>, Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>, 
	David Rientjes <rientjes@...gle.com>, Joonsoo Kim <iamjoonsoo.kim@....com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Roman Gushchin <roman.gushchin@...ux.dev>, 
	Hyeonggon Yoo <42.hyeyoo@...il.com>, "Gustavo A . R . Silva" <gustavoars@...nel.org>, 
	Bill Wendling <morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>, Jann Horn <jannh@...gle.com>, 
	Przemek Kitszel <przemyslaw.kitszel@...el.com>, Marco Elver <elver@...gle.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Sasha Levin <sashal@...nel.org>, linux-mm@...ck.org, 
	Randy Dunlap <rdunlap@...radead.org>, Miguel Ojeda <ojeda@...nel.org>, 
	Matthew Wilcox <willy@...radead.org>, Vegard Nossum <vegard.nossum@...cle.com>, 
	Harry Yoo <harry.yoo@...cle.com>, Nathan Chancellor <nathan@...nel.org>, 
	Peter Zijlstra <peterz@...radead.org>, Nick Desaulniers <nick.desaulniers+lkml@...il.com>, 
	Jonathan Corbet <corbet@....net>, Jakub Kicinski <kuba@...nel.org>, Yafang Shao <laoar.shao@...il.com>, 
	Tony Ambardar <tony.ambardar@...il.com>, Alexander Lobakin <aleksander.lobakin@...el.com>, 
	Jan Hendrik Farr <kernel@...rr.cc>, Alexander Potapenko <glider@...gle.com>, linux-kernel@...r.kernel.org, 
	linux-hardening@...r.kernel.org, linux-doc@...r.kernel.org, 
	llvm@...ts.linux.dev
Subject: Re: [PATCH v5 2/4] slab: Introduce kmalloc_obj() and family

On Mon, 24 Nov 2025 at 16:29, Kees Cook <kees@...nel.org> wrote:
>
> On Mon, Nov 24, 2025 at 01:35:12PM -0800, Linus Torvalds wrote:
> > Those macros are illegible. And 99% of all users DO NOT WANT ANY OF
> > THAT COMPLEXITY.
>
> Okay, I think you're saying "I don't want the common helpers to include
> the infrastructure for supporting the ..._sz() variants"?

I don't want the macros to expand the code more than necessary,
because that just makes everything worse (including very much my build
times - which have gotten worse over the years, but historically my
build environment got faster at an even higher rate - that is no
longer true).

I also want the macros to be somewhat understandable.

Yes, we have some macros that are works of art because they are *so*
obscure and are fundamentally hard to understand because they play
games with really really subtle language semantics.

And then I enjoy them and appreciate the insanity of them. I still
think our __is_constexpr() macro is truly a wonder, but we do have 40
lines of comment (!) for that one strange macro.

But this was not *that* kind of hard-to-understand macro. This was
just overly complicated.

> Fair enough. Looking at the treewide change I prepared[1], it's less
> than 1% of those mechanical replacements:

Yeah, I did some numbers on my simple version, and just the three
simple ones were the majority of cases by far.

I also believe that when we're doing more complicated size
calculations (ie the whole "struct_size()" patterns), then the
advantage of merging them with the allocation itself is questionable,
simply because it takes two different pieces and makes them one
*compilcated* piece.

Doing

        size = struct_size(ptr, flex_member, count);
        ptr = kmalloc(size, gfp);

is basically two fairly straightforward things and easy to understand.
You can *scan* that code, and each piece is simple enough that it
makes intuitive sense.

No, 'struct_size()' isn't exactly a very intuitive thing, but written
that way it's also not very surprising or complicated to parse at a
glance.

In contrast,

        ptr = kmalloc_flex_sz(*ptr, flex_member, count, gfp, &size);

does *not* make intuitive sense, I believe. Now you have five
different arguments, and it's actually somewhat hard to parse, and
there are odd semantics.

In contrast, the simple versions that take

        ptr = kmalloc(sizeof(*ptr), gfp);

and turn it into

        ptr = kmalloc_obj(*ptr, gfp);

actually become *simpler* to read and understand.

Yes, there are some other advantages to the combined version (ie that
whole thing where 'kmalloc_obj()' now returns a proper _type_ - type
safety is always good, and avoiding void pointers is a real thing),
but I do think that the major advantage is "simpler to read".

Because in the end, simple code that does what you intuitively expect
it to do, is good code, and hopefully less buggy.

             Linus