On Tue, 7 Apr 2026 at 14:54, 'Harry Yoo (Oracle)' via kasan-dev <[email protected]> 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 > > <[email protected]> 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
