On Fri, Jan 09, 2026 at 09:31:03AM -0800, Kees Cook wrote:
> On Thu, Jan 08, 2026 at 03:01:00PM +0100, Vlastimil Babka wrote:
> > On 12/4/25 00:30, Kees Cook wrote:
> > > [...]
> > > +/**
> > > + * __alloc_objs - Allocate objects of a given type using
> > > + * @KMALLOC: which size-based kmalloc wrapper to allocate with.
> > > + * @GFP: GFP flags for the allocation.
> > > + * @TYPE: type to allocate space for.
> > > + * @COUNT: how many @TYPE objects to allocate.
> > > + *
> > > + * Returns: Newly allocated pointer to (first) @TYPE of @COUNT-many
> > > + * allocated @TYPE objects, or NULL on failure.
> > > + */
> > > +#define __alloc_objs(KMALLOC, GFP, TYPE, COUNT)
> > > \
> > > +({
> > > \
> > > + const size_t __obj_size = size_mul(sizeof(TYPE), COUNT); \
> >
> > I assume with the hardcoded 1 for COUNT, this size_mul() will be eliminated
> > by the compiler and not add unnecessary runtime overhead? Otherwise we
> > should have two core #define variants.
>
> You're correct: the compiler completely collapses it with 0 runtime
> overhead; a variant is not needed.
>
> > I also noted that the existing kmalloc_array() and kvmalloc_array() do
> > check_mul_overflow() and return NULL silently on overflow. This AFAIU will
> > make SIZE_MAX passed to the underlying kmalloc/kvmalloc and thus will cause
> > a warning. That's IMHO a good thing.
>
> Right -- I prefer seeing the SIZE_MAX yelling from the allocator. Should
> we change how k*malloc_array() behaves?
Huh, yeah, it's weird to not get a stack trace if kmalloc() fails. On
the other hand, if we're allocating SIZE_MAX, that is probably a user
controlled size. Since we don't want people spamming dmesg, it should
probably be WARN_ONCE().
regards,
dan carpenter
