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

[Marco Elver <elver@google.com>]

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.

Which is sad, because that means we need the macro workaround.

Do you want to be credited with Co-authored-by - in which case I need
your Signed-off-by.

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

Thanks,
-- Marco