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

[Suren Baghdasaryan]

On Mon, Jun 29, 2026 at 9:42 PM Harry Yoo <harry@xxxxxxxxxx> wrote:
>
>
>
> 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 :)

Nice! I suggest posting Shakeel's patch CC'ing stable for backports
and then following up with the fix using KMALLOC_TYPE. Vlastimil,
WDYT?

>
> >> KMALLOC_TYPE as a replacement.
> >
> > And Shakeel's patch is easily backportable.
>
> Yes, of course!
>
> --
> Cheers,
> Harry / Hyeonggon
>