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

[Suren Baghdasaryan]

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.

Yes, it's worth backporting, so we can merge Shakeel's change as is
and then once Vlastimil's patch is merged we can implement the new
KMALLOC_TYPE as a replacement.

>
> > 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
>