Re: [PATCH v4 5/7] mm/slab: Provide kmalloc type fallback for bucket allocations

[Kees Cook]

On Tue, Sep 22, 2026 at 11:11:58AM +0100, Pedro Falcato wrote:
> Big thanks for continuing this effort :))

Thanks for starting it! :) I've had a few folks wanting it, so I'm happy
to help.

> On Mon, Sep 21, 2026 at 12:58:16AM -0700, Kees Cook wrote:
> [...]
> > +/*
> > + * The kmalloc types a bucket set can hold a copy of. This is deliberately not
> > + * enum kmalloc_cache_type: the KMALLOC_PARTITION copies are all "normal" to a
> > + * bucket set, which already separates what they were there to separate, so
> > + * indexing by those would mean up to KMALLOC_PARTITION_CACHES_NR unusable
> > + * rows per set. Allocations of any type not listed here are served by the
> > + * general caches.
> > + */
> 
> This sounds odd. Is there a good reason why KMALLOC_PARTITIONs are kmalloc_cache_types?
> Perhaps that bit should be reworked instead?

I'm not sure I follow. Do you mean the partition copies themselves
shouldn't be kmalloc_cache_types? That predates this series. For a
bucket set, they're all the same "normal" type, so a set indexed by
kmalloc_cache_type would carry rows it can never use: on x86_64 with
CONFIG_KMALLOC_PARTITION_CACHES=y, that's 20 rows (2240 bytes) per set
instead of 2 (224 bytes). I've put the numbers in the commit log for
v5.

> [...]
> > +	if (type <= KMALLOC_PARTITION_END)
> > +		btype = KMEM_BUCKET_NORMAL;
> > +	else
> > +		return &kmalloc_caches[type];	/* No set holds a row for it. */
> 
> Hitting this case sounds like a bug in the kernel. WARN_ON_ONCE()?

The next patch warns where a set could have held the row but wasn't
created with it (an accounted allocation without KMEM_BUCKET_CGROUP).
What's left here are types no set can hold, like DMA and reclaimable,
and those already come from caches of their own, so falling back
doesn't lose the separation.

> Otherwise LGTM.

Thanks!

-- 
Kees Cook