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

[Kees Cook]

On April 22, 2026 8:26:30 AM PDT, Marco Elver <elver@xxxxxxxxxx> wrote:
>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.

There is now the "transitional" Kconfig keyword too, which should make it easy to move to the new name.

For the naming, I tend to prefer the noun-verb (e.g. timer_start()) and noun-feature-option ordering (e.g. CONFIG_SLAB_FREELIST_RANDOM). This feature isn't about partition tables, so I don't think the first word should be "partition". :)

As far as doing the full isolation later, yeah, that's fine, and I think with this Kconfig change it's easy to add a new mode.

-Kees

-- 
Kees Cook