From: Matthew Wilcox <willy@infradead.org>
To: Kees Cook <kees@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
"Gustavo A . R . Silva" <gustavoars@kernel.org>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Jann Horn <jannh@google.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Marco Elver <elver@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sasha Levin <sashal@kernel.org>,
linux-mm@kvack.org, Miguel Ojeda <ojeda@kernel.org>,
Nathan Chancellor <nathan@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Jakub Kicinski <kuba@kernel.org>,
Yafang Shao <laoar.shao@gmail.com>,
Tony Ambardar <tony.ambardar@gmail.com>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Jan Hendrik Farr <kernel@jfarr.cc>,
Alexander Potapenko <glider@google.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-doc@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH v4 2/2] slab: Introduce kmalloc_obj() and family
Date: Tue, 7 Oct 2025 03:07:33 +0100 [thread overview]
Message-ID: <aOR15Xb6DfolYM0z@casper.infradead.org> (raw)
In-Reply-To: <20250315031550.473587-2-kees@kernel.org>
On Fri, Mar 14, 2025 at 08:15:45PM -0700, Kees Cook wrote:
> +Performing open-coded kmalloc()-family allocation assignments prevents
> +the kernel (and compiler) from being able to examine the type of the
> +variable being assigned, which limits any related introspection that
> +may help with alignment, wrap-around, or additional hardening. The
> +kmalloc_obj()-family of macros provide this introspection, which can be
> +used for the common code patterns for single, array, and flexible object
> +allocations. For example, these open coded assignments::
> +
> + ptr = kmalloc(sizeof(*ptr), gfp);
> + ptr = kmalloc(sizeof(struct the_type_of_ptr_obj), gfp);
> + ptr = kzalloc(sizeof(*ptr), gfp);
> + ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> + ptr = kcalloc(count, sizeof(*ptr), gfp);
> + ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
> +
> +become, respectively::
> +
> + kmalloc_obj(ptr, gfp);
> + kzalloc_obj(ptr, gfp);
> + kmalloc_objs(ptr, count, gfp);
> + kzalloc_objs(ptr, count, gfp);
> + kmalloc_flex(ptr, flex_member, count, gfp);
I'd like to propose a different approach for consideration.
The first two are obvious. If we now believe that object type is the
important thing, well we have an API for that:
struct buffer_head { ... };
bh_cache = KMEM_CACHE(buffer_head, SLAB_RECLAIM_ACCOUNT);
...
ptr = kmem_cache_alloc(bh_cache, GFP_KERNEL);
It's a little more verbose than what you're suggesting, but it does give
us the chance to specify SLAB_ flags. It already does the alignment
optimisation you're suggesting. Maybe we can use some macro sugar to
simplify this.
The array ones are a little tougher. Let's set them aside for the
moment and tackle the really hard one; kmalloc_flex.
Slab is fundamentally built on all objects in the slab being the same
size. But maybe someone sufficiently enterprising could build a
"variable sized" slab variant? If we're saying that object type is
more important a discriminator than object size, then perhaps grouping
objects of the same size together isn't nearly as useful as grouping
objects of the same type together, even if they're different sizes.
Might be a good GSoC/outreachy project?
next prev parent reply other threads:[~2025-10-07 2:07 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-15 3:15 [PATCH v4 0/2] " Kees Cook
2025-03-15 3:15 ` [PATCH v4 1/2] compiler_types: Introduce __flex_counter() " Kees Cook
2025-03-15 4:53 ` Randy Dunlap
2025-03-15 18:34 ` Kees Cook
2025-03-15 19:47 ` Miguel Ojeda
2025-03-15 21:06 ` Kees Cook
2025-03-17 9:26 ` Przemek Kitszel
2025-03-17 9:43 ` Przemek Kitszel
2025-03-17 16:22 ` Kees Cook
2025-03-15 3:15 ` [PATCH v4 2/2] slab: Introduce kmalloc_obj() " Kees Cook
2025-03-15 5:18 ` Gustavo A. R. Silva
2025-03-15 18:02 ` Randy Dunlap
2025-03-15 18:39 ` Kees Cook
2025-03-15 18:31 ` Linus Torvalds
2025-03-15 18:56 ` Kees Cook
2025-03-15 19:06 ` Linus Torvalds
2025-10-07 2:07 ` Matthew Wilcox [this message]
2025-10-07 17:17 ` Kees Cook
2025-10-07 17:47 ` Christoph Lameter (Ampere)
2025-10-07 18:18 ` Marco Elver
2025-10-08 4:20 ` Kees Cook
2025-10-08 7:49 ` Vegard Nossum
2025-10-09 12:07 ` Marco Elver
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aOR15Xb6DfolYM0z@casper.infradead.org \
--to=willy@infradead.org \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aleksander.lobakin@intel.com \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=gustavoars@kernel.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=jannh@google.com \
--cc=justinstitt@google.com \
--cc=kees@kernel.org \
--cc=kernel@jfarr.cc \
--cc=kuba@kernel.org \
--cc=laoar.shao@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=ojeda@kernel.org \
--cc=penberg@kernel.org \
--cc=peterz@infradead.org \
--cc=przemyslaw.kitszel@intel.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=sashal@kernel.org \
--cc=tony.ambardar@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox