Re: [PATCH v2] slab: support for compiler-assisted type-based slab cache partitioning

[Marco Elver <elver@google.com>]

On Tue, Apr 21, 2026 at 09:13PM +0200, Marco Elver wrote:
[...]
> > And actually, perhaps a global rename of the options so the selection
> > naming is at the end of the CONFIG phrase, and bundle the on/off into
> > the choice:
> >
> >
> > choice
> >         prompt "Partitioned slab cache mode"
> >         depends on PARTITION_KMALLOC_CACHES
> >         default KMALLOC_PARTITION_TYPED if !SLUB_TINY && CC_HAS_ALLOC_TOKEN
> >         default KMALLOC_PARTITION_RANDOM if !SLUB_TINY
> >         default KMALLOC_PARTITION_NONE
> >
> > config KMALLOC_PARTITION_NONE
> > ...
> > config KMALLOC_PARTITION_RANDOM
> >         depends on !SLUB_TINY
> > ...
> > config KMALLOC_PARTITION_TYPED
> >         depends on !SLUB_TINY && CC_HAS_ALLOC_TOKEN
> 
> There was a comment somewhere else that even introducing
> PARTITION_KMALLOC_CACHES might confuse users of RANDOM_KMALLOC_CACHES.
> I think completely getting rid of and renaming RANDOM_KMALLOC_CACHES
> has marginal benefit, and will cause friction for existing users (even
> moreso than already). I see little benefit here, and would prefer not
> to break user configs more than needed: configs that already set
> RANDOM_KMALLOC_CACHES, upon rebuild will be prompted to enable
> PARTITION_KMALLOC_CACHES; if user says Y, then their previous
> selection (RANDOM) would already be picked and they don't have to
> rediscover that it exists under a new name.
> 
> I can make this change, but only if you're sure the benefit outweighs
> the downsides here.

Upon further reflection, since the transition isn't smooth anyway, I'm
probably going to rename, but have them all use the PARTITION_KMALLOC_*
prefix so it's easy to just search for "CONFIG_PARTITION_KMALLOC_". I
don't see the need for a "NONE" variant - I've seen this pattern
elsewhere, and then you end up with users reading the .config and
concluding "CONFIG_PARTITION_KMALLOC_CACHES is enabled ... but oh never
mind actually it isn't" which I find confusing. This could be useful if
we had a dynamic on/off toggle and the default is NONE, but that's not
the case here.

diff --git a/Makefile b/Makefile
index f70170ed1522..d1f63ffb85f0 100644
--- a/Makefile
+++ b/Makefile
@@ -989,7 +989,7 @@ KBUILD_CFLAGS	+= $(CC_AUTO_VAR_INIT_ZERO_ENABLER)
 endif
 endif
 
-ifdef CONFIG_TYPED_KMALLOC_CACHES
+ifdef CONFIG_PARTITION_KMALLOC_TYPED
 # PARTITION_KMALLOC_CACHES_NR + 1
 KBUILD_CFLAGS	+= -falloc-token-max=16
 endif
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 0537c3596163..b46300037ca5 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -501,10 +501,10 @@ int kmem_cache_shrink(struct kmem_cache *s);
 
 #ifdef CONFIG_PARTITION_KMALLOC_CACHES
 typedef struct { unsigned long v; } kmalloc_token_t;
-#ifdef CONFIG_RANDOM_KMALLOC_CACHES
+#ifdef CONFIG_PARTITION_KMALLOC_RANDOM
 extern unsigned long random_kmalloc_seed;
 #define __kmalloc_token(...) ((kmalloc_token_t){ .v = _RET_IP_ })
-#elif defined(CONFIG_TYPED_KMALLOC_CACHES)
+#elif defined(CONFIG_PARTITION_KMALLOC_TYPED)
 #define __kmalloc_token(...) ((kmalloc_token_t){ .v = __builtin_infer_alloc_token(__VA_ARGS__) })
 #endif
 #define DECL_TOKEN_PARAM(_token)	, kmalloc_token_t (_token)
@@ -732,11 +732,11 @@ static __always_inline enum kmalloc_cache_type kmalloc_type(gfp_t flags, kmalloc
 	 * with a single branch for all the relevant flags.
 	 */
 	if (likely((flags & KMALLOC_NOT_NORMAL_BITS) == 0))
-#ifdef CONFIG_RANDOM_KMALLOC_CACHES
+#ifdef CONFIG_PARTITION_KMALLOC_RANDOM
 		/* PARTITION_KMALLOC_CACHES_NR (=15) copies + the KMALLOC_NORMAL */
 		return KMALLOC_PARTITION_START + hash_64(token.v ^ random_kmalloc_seed,
 							 ilog2(PARTITION_KMALLOC_CACHES_NR + 1));
-#elif defined(CONFIG_TYPED_KMALLOC_CACHES)
+#elif defined(CONFIG_PARTITION_KMALLOC_TYPED)
 		return KMALLOC_PARTITION_START + token.v;
 #else
 		return KMALLOC_NORMAL;
diff --git a/mm/Kconfig b/mm/Kconfig
index 6d44bd2633bb..d8510913fbeb 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -265,12 +265,12 @@ config PARTITION_KMALLOC_CACHES
 choice
 	prompt "Partitioned slab cache mode"
 	depends on PARTITION_KMALLOC_CACHES
-	default TYPED_KMALLOC_CACHES if CC_HAS_ALLOC_TOKEN
-	default RANDOM_KMALLOC_CACHES
+	default PARTITION_KMALLOC_TYPED if CC_HAS_ALLOC_TOKEN
+	default PARTITION_KMALLOC_RANDOM
 	help
 	  Selects the slab cache partitioning mode.
 
-config RANDOM_KMALLOC_CACHES
+config PARTITION_KMALLOC_RANDOM
 	bool "Randomize slab caches for normal kmalloc"
 	help
 	  Randomly pick a slab cache based on code address and a per-boot
@@ -282,17 +282,17 @@ config RANDOM_KMALLOC_CACHES
 	  the randomization by retrying attacks across multiple machines until
 	  the target objects are co-located.
 
-config TYPED_KMALLOC_CACHES
+config PARTITION_KMALLOC_TYPED
 	bool "Type based slab cache selection for normal kmalloc"
 	depends on CC_HAS_ALLOC_TOKEN
 	help
 	  Rely on Clang's allocation tokens to choose a slab cache, where token
 	  IDs are derived from the allocated type.
 
-	  Unlike RANDOM_KMALLOC_CACHES, cache assignment is deterministic based
+	  Unlike PARTITION_KMALLOC_RANDOM, cache assignment is deterministic based
 	  on type, which guarantees that objects of certain types are not
 	  placed in the same cache. This effectively mitigates certain classes
-	  of exploits that probabilistic defenses like RANDOM_KMALLOC_CACHES
+	  of exploits that probabilistic defenses like PARTITION_KMALLOC_RANDOM
 	  only make harder but not impossible. However, this also means the
 	  cache assignment is predictable.
 
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 21ab7dd79b5e..ca5e2a6d4e46 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -742,7 +742,7 @@ kmem_buckets kmalloc_caches[NR_KMALLOC_TYPES] __ro_after_init =
 { /* initialization for https://llvm.org/pr42570 */ };
 EXPORT_SYMBOL(kmalloc_caches);
 
-#ifdef CONFIG_RANDOM_KMALLOC_CACHES
+#ifdef CONFIG_PARTITION_KMALLOC_RANDOM
 unsigned long random_kmalloc_seed __ro_after_init;
 EXPORT_SYMBOL(random_kmalloc_seed);
 #endif
@@ -1010,7 +1010,7 @@ void __init create_kmalloc_caches(void)
 		for (i = KMALLOC_SHIFT_LOW; i <= KMALLOC_SHIFT_HIGH; i++)
 			new_kmalloc_cache(i, type);
 	}
-#ifdef CONFIG_RANDOM_KMALLOC_CACHES
+#ifdef CONFIG_PARTITION_KMALLOC_RANDOM
 	random_kmalloc_seed = get_random_u64();
 #endif