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

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:
[...]

quoted

+/*
+ * 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.

[...]

quoted

+	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