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

[Suren Baghdasaryan]

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

And Shakeel's patch is easily backportable.

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