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

[Pedro Falcato]

Hi Kees,

Big thanks for continuing this effort :))

On Mon, Sep 21, 2026 at 12:58:16AM -0700, Kees Cook wrote:
> kmem_buckets_create() clones kmalloc_caches[KMALLOC_NORMAL].
> kmalloc_slab() figures out the kmalloc type the caller asks for, but
> then ignored it whenever a bucket set was in use, returning a normal
> cache regardless. This would be a problem if a caller asked for GFP_DMA,
> __GFP_ACCOUNT, etc. None of the current users do this, so there is
> problem, but it makes adding new users fragile. For example, skb data[1]
> needs to handle GFP_DMA (rarely) and __GFP_ACCOUNT (often).
> 
> Send those allocations to the general caches instead so nothing breaks and
> regular allocations remain isolated with the bucket. The kmem_bucket_type
> enum contains only a single item here, but will be expanded in the next
> patch.
> 
> Built and tests pass with ARCH=x86_64 defconfig with GCC 16.2.0, with
> CONFIG_SLAB_BUCKETS as y and n.
> 
> Assisted-by: LLM
> Link: https://lore.kernel.org/all/04debe19-bbe8-4b5f-9668-753d1f97832d@xxxxxxxxxx/ [1]
> Signed-off-by: Kees Cook <kees@xxxxxxxxxx>
> ---
> Cc: Vlastimil Babka <vbabka@xxxxxxxxxx>
> Cc: Harry Yoo <harry@xxxxxxxxxx>
> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> Cc: Hao Li <hao.li@xxxxxxxxx>
> Cc: Christoph Lameter <cl@xxxxxxxxxx>
> Cc: David Rientjes <rientjes@xxxxxxxxxx>
> Cc: Roman Gushchin <roman.gushchin@xxxxxxxxx>
> Cc: <linux-mm@xxxxxxxxx>
> Cc: Pedro Falcato <pfalcato@xxxxxxx>
> Cc: Kuniyuki Iwashima <kuniyu@xxxxxxxxxx>
> Cc: <linux-hardening@xxxxxxxxxxxxxxx>
> ---
>  include/linux/slab.h   | 13 +++++++++++
>  mm/slab.h              | 23 ++++++++++++++++--
>  lib/tests/slub_kunit.c | 53 ++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 87 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index 18a2351f9084..ab9ab3d34847 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -742,6 +742,19 @@ typedef struct kmem_cache * kmem_buckets[KMALLOC_SHIFT_HIGH + 1];
>  
>  extern kmem_buckets kmalloc_caches[NR_KMALLOC_TYPES];
>  
> +/*
> + * 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?

> +enum kmem_bucket_type {
> +	KMEM_BUCKET_NORMAL = 0,
> +	NR_KMEM_BUCKET_TYPES
> +};
> +
>  /*
>   * Define gfp bits that should not be set for KMALLOC_NORMAL.
>   */
> diff --git a/mm/slab.h b/mm/slab.h
> index 8fd6835e4235..7f1bfee83b92 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -421,6 +421,26 @@ static inline unsigned int size_index_elem(unsigned int bytes)
>  	return (bytes - 1) / 8;
>  }
>  
> +/*
> + * Which set of buckets to use for the given kmalloc_cache_type. If not
> + * handled by the kmem_buckets, fall back to general caches.
> + */
> +static inline kmem_buckets *
> +kmalloc_choose_bucket(kmem_buckets *bucket, enum kmalloc_cache_type type)
> +{
> +	enum kmem_bucket_type btype;
> +
> +	if (!bucket)
> +		return &kmalloc_caches[type];
> +
> +	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()?

Otherwise LGTM.

-- 
Pedro