Re: [PATCH] mm/slub: serve slabobj_ext array from a strictly larger kmalloc cache

[Harry Yoo <harry@kernel.org>]

On 6/29/26 1:28 PM, Suren Baghdasaryan wrote:
> On Sun, Jun 28, 2026 at 8:57 PM Harry Yoo <harry@kernel.org> wrote:
>>> I think adding a new KMALLOC_TYPE would be the cleanest way to fix
>>> this recursion problem once and for all. This size bumping and the
>>> special case of SLUB_TINY are quite confusing.
>>
>> As mentioned by Vlsatimil, in the long term, using SLAB_BUCKETS
>> infrastructure would be more straightforward than new KMALLOC_TYPE
>> because (I think) the kmalloc type is decided purely based on GFP
>> flags and we need to somehow work around that. SLAB_BUCKETS provides
>> a nice abstraction to do this.
>>
>> Luckily, SLAB_BUCKETS is introduced in v6.11.
>> Unfortunately, SLAB_BUCKETS is optional.
>>
>>> We could define that> new KMALLOC_TYPE only if memory allocation profiling or SLUB_TINY are
>>> enabled to avoid new caches when not needed. Does not seem too complex
>>> but maybe I'm missing something? WDYT?
>>
>> I think we need some enhancements to achieve that with SLAB_BUCKETS
>>
>> 1. Rename SLAB_BUCKETS to SLAB_BUCKETS_HARDENING
>>     (w/ SLAB_BUCKETS being a transitional config for _HARDENING)
>>
>> 2. Make the SLAB_BUCKETS infrastructure unconditional,
>>     but the decision is made at runtime:
>>
>>     1) actually creating a kmem_buckets vs.
>>     2) falling back to kmalloc.
>>
>> 3. kmem_buckets_create() creates kmem_buckets only when
>>     SLAB_BUCKETS_HARDENING is enabled.
>>
>> 4. SLUB decides (not) to create kmem_buckets for internal use
>>     during the boot process. Use the kmem_buckets for obj_exts
>>     array allocation.
>>
>> Side note: this would unconditionally add the kmem_buckets parameter to
>> the kmalloc slowpath. Probably it'd be worth introducing a dedicated
>> entrypoint for kmem_buckets instead.
> 
> Yeah, this sounds quite complex.

I think it's not that complex, but quite some churn, yeah :)

> Maybe we could use the new> kmalloc_flags() introduced by Vlastimil 
 > in [1] to avoid using GFP
> flags to indicate that we want to use this new KMALLOC_TYPE? That
> seems simpler,

That indeed would be smaller changes.

> though it's not backportable because kmalloc_flags() is> brand new.

Right, I didn't seriously consider that option as I was (mistakenly) 
assuming you or Shakeel would want to backport it.

> [1] https://lore.kernel.org/all/20260615-slab_alloc_flags-v3-0-ce1146d140fb@kernel.org/
> 
>>
>>> If it is more complex than I imaging then I'm fine with Shakeel's
>>> approach as a temporary fix.
>>
>> Since above requires quite some changes, I'd say let's proeed with
>> the fix (since it's one line of code change that fixes a bug),
>> and then see how we can make SLAB_BUCKETS changes as minimal
>> as possible for backporting?
> 
> I was thinking Shakeel's approach for backports and
> kmalloc_flags()+KMALLOC_TYPE going forward.

Oh, I misread it then.
I was assuming it's critical enough to bother backporting.

> Just throwing this as an> option. I haven't looked closely into 
 > SLAB_BUCKETS yet, so that might
> be indeed a better direction.
-- 
Cheers,
Harry / Hyeonggon