On Thu, Jan 08, 2026 at 03:01:00PM +0100, Vlastimil Babka wrote:
> On 12/4/25 00:30, Kees Cook wrote:
> > Introduce type-aware kmalloc-family helpers to replace the common
> > idioms for single object and arrays of objects allocation:
> > 
> >     ptr = kmalloc(sizeof(*ptr), gfp);
> >     ptr = kmalloc(sizeof(struct some_obj_name), gfp);
> >     ptr = kzalloc(sizeof(*ptr), gfp);
> >     ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> >     ptr = kcalloc(count, sizeof(*ptr), gfp);
> > 
> > These become, respectively:
> > 
> >     ptr = kmalloc_obj(*ptr, gfp);
> >     ptr = kmalloc_obj(*ptr, gfp);
> >     ptr = kzalloc_obj(*ptr, gfp);
> >     ptr = kmalloc_objs(*ptr, count, gfp);
> >     ptr = kzalloc_objs(*ptr, count, gfp);
> > 
> > Beyond the other benefits outlined below, the primary ergonomic benefit
> > is the elimination of needing "sizeof" nor the type name, and the
> > enforcement of assignment types (they do not return "void *", but rather
> > a pointer to the type of the first argument). The type name _can_ be
> > used, though, in the case where an assignment is indirect (e.g. via
> > "return"). This additionally allows[1] variables to be declared via
> > __auto_type:
> > 
> >     __auto_type ptr = kmalloc_obj(struct foo, gfp);
> > 
> > Internal introspection of the allocated type now becomes possible,
> > allowing for future alignment-aware choices to be made by the allocator
> > and future hardening work that can be type sensitive. For example,
> > adding __alignof(*ptr) as an argument to the internal allocators so that
> > appropriate/efficient alignment choices can be made, or being able to
> > correctly choose per-allocation offset randomization within a bucket
> > that does not break alignment requirements.
> > 
> > Link: 
> > https://lore.kernel.org/all/CAHk-=wicotw5ufturanvjkr6769d29tf7of79gujdqhs_tk...@mail.gmail.com/
> >  [1]
> > Signed-off-by: Kees Cook <[email protected]>
> 
> Acked-by: Vlastimil Babka <[email protected]>
> 
> How do you plan to handle this series? Given minimal slab changes (just
> wrappers) but there being also changes elsewhere, want to use your hardening
> tree? I wouldn't mind.

Ah! Sure, yeah, I can take it. Thanks for the Ack. I'll get it into
-next and refresh the treewide changes.

-Kees

-- 
Kees Cook

Reply via email to