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] [day] [month] [year] [list]

Message-ID: <fafb77fa-0615-4404-b976-be1a5496a96f@intel.com>
Date: Mon, 1 Dec 2025 11:49:16 +0100
From: Przemek Kitszel <przemyslaw.kitszel@...el.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>, 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>, 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

> 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

what about below interface:
	ptr = kmalloc_flex(*ptr, member, count, gfp);
	size = kmalloc_flex_get_size(ptr);

so, users that don't care about size would not need to read or store it

but those that need the size (likely to pass the whole struct via some
generic interface) will simply ask for it

note that there are some caveats, like user could add something like
	ptr->count++;
to destroy naive implementation for kmalloc_flex_get_size() above,
but we don't need to make knee shooting any less painful

another note, there is ksize(), and if we would like to waste some more
for actual size asked (as opposed to allocated), there could be a proper
function (instead of the macro that will work only when user not messing
with conventions) for kmalloc_flex_get_size()