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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAHk-=wiNnECns4B3qxRsCykkHwzovT+3wG738fUhq5E+3Lxxbg@mail.gmail.com>
Date: Sat, 22 Nov 2025 11:53:33 -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

Honestly, I hate this.

In particular, I intensely dislike that horrendous 'SIZE' parameter to
those helper macros, and this just needs to die.

The argument for that horror is also just silly:

On Fri, 21 Nov 2025 at 17:43, Kees Cook <kees@...nel.org> wrote:
>
> These each return the newly allocated pointer to the type (which may be
> NULL on failure). For cases where the total size of the allocation is
> needed, the kmalloc_obj_sz(), kmalloc_objs_sz(), and kmalloc_flex_sz()
> family of macros can be used. For example:
>
>         size = struct_size(ptr, flex_member, count);
>         ptr = kmalloc(size, gfp);
>
> becomes:
>
>         ptr = kmalloc_flex_sz(*ptr, flex_member, count, gfp, &size);

That thing is ACTIVELY WORSE than the code it replaces.

One of them makes sense and is legible toi a normal human.

The other does not.

The alleged advantage is apparently that you can do it on one line,
but when that one line is just horrible garbage, that is not an
advantyage at all.

And the impact of that crazy SIZE on the macro expansions makes the
whole thing entirely illegible.

I will not merge anything this broken.

The whole "limit to pre-defined size" argument is also just crazy,
because now the SIZE parameter suddenly gets a second meaning. EVEN
WORSE.

Finally, I think the parts of this that aren't wrong are too limited,
and do not go far enough.

Because once you give that "alloc_obj()" an actual type, it should
take the alignment of the type into account too.

I also think this part:

+       typeof(VAR) *__obj_ptr = NULL;                                  \
+       if (!WARN_ON_ONCE(!__can_set_flex_counter(__obj_ptr->FAM, __count)) && \

absolutely needs to die.  You just set __obj_ptr to NULL, and then you
use __obj_ptr->FAM. Now, it so happens that __can_set_flex_counter()
only cares about the *type*, but dammit, this kind of code sequence is
simply not acceptable, and it needs to make that *explicit* by using
sane syntax like perhaps just spelling that out, using VAR, not that
NULL value.

IOW. making it use something like "typeof(VAR.FAM)" might work. Not
that crazy garbage.

I never want to see this kind of horrendous patch again. Everything
about it just screamed "disgusting".

                        Linus