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 > <[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.
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) <[email protected]> > > 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
