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/[email protected]/ > [1] > Signed-off-by: Kees Cook <[email protected]> > --- > Cc: Vlastimil Babka <[email protected]> > Cc: Harry Yoo <[email protected]> > Cc: Andrew Morton <[email protected]> > Cc: Hao Li <[email protected]> > Cc: Christoph Lameter <[email protected]> > Cc: David Rientjes <[email protected]> > Cc: Roman Gushchin <[email protected]> > Cc: <[email protected]> > Cc: Pedro Falcato <[email protected]> > Cc: Kuniyuki Iwashima <[email protected]> > Cc: <[email protected]> > --- > 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
