Re: [tip:locking/core] [futex] b78b0b6582: kselftests.damon.sysfs_memcg_path_leak.sh.fail

[Catalin Marinas <catalin.marinas@arm.com>]

On Fri, Aug 07, 2026 at 05:23:53PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 07, 2026 at 07:49:27AM -0700, SJ Park wrote:
> > > > kernel test robot noticed "kselftests.damon.sysfs_memcg_path_leak.sh.fail" on:
> > > > 
> > > > commit: b78b0b65825275f58336a43611a700de174be8c3 ("futex: Use runtime constants for __futex_hash() hot path")
> > > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git locking/core
> 
> > The test does a simple DAMON operation and runs kmemleak to see if it caused a
> > leak.  It doesn't filter out leaks caused by something other than the DAMON
> > operation, though.  So the test can fail even if there is a leak outside of
> > DAMON.  This failure is the case.  I confirmed manual kmemleak run without any
> > DAMON operation reports the leak on the kernel that was built with the reported
> > commit [1] like below.
> 
> > So, the commit is not breaking DAMON.  But apparently it is leaking something.
> 
> Well, its doing a __init allocation and never freeing it because well,
> futexes cannot be unloaded or anything.
> 
> Catalin, this seems rather daft, but what do I know. Is the below the
> right way to tell it to STFU?
> 
> ---
> diff --git a/kernel/futex/core.c b/kernel/futex/core.c
> index ad917ff83854..afdbaf754fb7 100644
> --- a/kernel/futex/core.c
> +++ b/kernel/futex/core.c
> @@ -45,6 +45,7 @@
>  #include <linux/rseq.h>
>  #include <linux/slab.h>
>  #include <linux/vmalloc.h>
> +#include <linux/kmemleak.h>
>  
>  #include <vdso/futex.h>
>  
> @@ -2058,6 +2059,7 @@ static int __init futex_init(void)
>  	order = get_order(size);
>  
>  	__futex_queues = kcalloc(nr_node_ids, sizeof(*__futex_queues), GFP_KERNEL);
> +	kmemleak_not_leak(__futex_queues);
>  
>  	runtime_const_init(shift, __futex_shift);
>  	runtime_const_init(mask,  __futex_mask);

This would do. Kmemleak is not that advanced to track the
runtime_const_init() pointers.

-- 
Catalin