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

[Harry Yoo]

On 6/30/26 1:39 PM, Suren Baghdasaryan wrote:
> On Mon, Jun 29, 2026 at 9:38 PM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
>>
>> On Mon, Jun 29, 2026 at 7:31 PM Harry Yoo <harry@xxxxxxxxxx> wrote:
>>>
>>>
>>>
>>> On 6/29/26 1:28 PM, Suren Baghdasaryan wrote:
>>>> On Sun, Jun 28, 2026 at 8:57 PM Harry Yoo <harry@xxxxxxxxxx> 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@xxxxxxxxxx/
>>>>
>>>>>
>>>>>> 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.

Ah, here I meant backporting either the kmalloc_flags()+KMALLOC_TYPE or
SLAB_BUCKETS approach.

>> Yes, it's worth backporting, so we can merge Shakeel's change as is

Right.

>> and then once Vlastimil's patch is merged we can implement the new

Vlastimil's patch has already landed mainline, by the way :)

>> KMALLOC_TYPE as a replacement.
> 
> And Shakeel's patch is easily backportable.

Yes, of course!

-- 
Cheers,
Harry / Hyeonggon