Re: [PATCH v1] slab: support for compiler-assisted type-based slab cache partitioning

["Harry Yoo (Oracle)" <harry@kernel.org>]

On Thu, Apr 09, 2026 at 10:19:09PM +0200, Marco Elver wrote:
> On Tue, 7 Apr 2026 at 14:54, 'Harry Yoo (Oracle)' via kasan-dev
> <kasan-dev@googlegroups.com> wrote:
> >
> > On Tue, Apr 07, 2026 at 01:17:14PM +0200, Marco Elver wrote:
> > > On Mon, 6 Apr 2026 at 06:28, 'Harry Yoo (Oracle)' via kasan-dev
> > > <kasan-dev@googlegroups.com> wrote:
> > > > On Fri, Apr 03, 2026 at 08:29:22PM +0200, Vlastimil Babka (SUSE) wrote:
> > > > > On 4/3/26 08:27, Harry Yoo (Oracle) wrote:
> > > > > >> diff --git a/include/linux/slab.h b/include/linux/slab.h
> > > > > >> index 15a60b501b95..c0bf00ee6025 100644
> > > > > >> --- a/include/linux/slab.h
> > > > > >> +++ b/include/linux/slab.h
> > > > > >> @@ -864,10 +877,10 @@ unsigned int kmem_cache_sheaf_size(struct slab_sheaf *sheaf);
> > > > > >>   * with the exception of kunit tests
> > > > > >>   */
> > > > > >>
> > > > > >> -void *__kmalloc_noprof(size_t size, gfp_t flags)
> > > > > >> +void *__kmalloc_noprof(size_t size, gfp_t flags, kmalloc_token_t token)
> > > > > >>                            __assume_kmalloc_alignment __alloc_size(1);
> > > > > >>
> > > > > >> -void *__kmalloc_node_noprof(DECL_BUCKET_PARAMS(size, b), gfp_t flags, int node)
> > > > > >> +void *__kmalloc_node_noprof(DECL_BUCKET_PARAMS(size, b), gfp_t flags, int node, kmalloc_token_t token)
> > > > > >>                            __assume_kmalloc_alignment __alloc_size(1);
> > > > > >
> > > > > > So the @token parameter is unused when CONFIG_PARTITION_KMALLOC_CACHES is
> > > > > > disabled but still increases the kernel size by a few kilobytes...
> > > > > > but yeah I'm not sure if we can get avoid it without hurting readability.
> > > > > >
> > > > > > Just saying. (does anybody care?)
> > > > >
> > > > > Well we did care enough with CONFIG_SLAB_BUCKETS to hide the unused param
> > > > > using DECL_BUCKET_PARAMS(),
> > > >
> > > > Hmm yeah.
> > > >
> > > > I wasn't sure if we could do this without hurting readability,
> > > > but perhaps we could...
> > > >
> > > > > so maybe extend that idea?
> > > > > I think it's not just kernel size, but increased register pressure etc.
> > >
> > > I'll take a closer look at generated code.
> >
> > > In some cases the compiler ought to omit zero-sized arguments,
> >
> > Oh, didn't know that was a thing.
> 
> So I checked with Clang and GCC. Looks like Clang does omit the
> zero-sized struct argument, i.e. generated code is identical to
> before. Whereas GCC wastes a few bytes of stack space at callsites.

Thanks for confirming that.

> Which is sad, because that means we need the macro workaround.
> 
> Do you want to be credited with Co-authored-by

I'd appreciate that. (I guess you meant Co-developed-by)

> - in which case I need your Signed-off-by.

Signed-off-by: Harry Yoo (Oracle) <harry@kernel.org>

> > Not sure if it's safe to do that for exported functions though (since
> > modules can be built w/ a different compiler).
> 
> Kernel modules built with a different config (implicit if different
> compiler) are not supported, and never have been. If it works, it's
> just luck (I know people do this, but it's just a disaster waiting to
> happen).

And if GCC folks somehow fix this at some point, even kernel modules
built with a different version of GCC might not be supported?

-- 
Cheers,
Harry / Hyeonggon