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

[Harry Yoo]

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.

> 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