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

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

[SJ Park]

Hello Peter,


Thank you for sharing this.

On Fri, 7 Aug 2026 11:01:39 +0200 Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, Aug 07, 2026 at 04:50:48PM +0800, kernel test robot wrote:
> > 
> > 
> > Hello,
> > 
> > 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
> > 
> > 
> > in testcase: kselftests
> > version: kselftests-x86_64-f5098b6bae76-1_20260727
> > with following parameters:
> > 
> > 	group: damon
> > 
> > 
> > 
> > config: x86_64-rhel-9.4-kselftests
> > compiler: gcc-14
> > test machine: 16 threads Intel(R) Core(TM) i7-13620H (Raptor Lake) with 32G memory
> > 
> > (please refer to attached dmesg/kmsg for entire log/backtrace)
> > 
> > 
> > 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <oliver.sang@intel.com>
> > | Closes: https://lore.kernel.org/oe-lkp/202608071053.6db6276e-lkp@intel.com
> > 
> > 
> > # timeout set to 300
> > # selftests: damon: sysfs_memcg_path_leak.sh
> > # unreferenced object 0xffff8881029e0ab8 (size 8):
> > #   comm "swapper/0", pid 1, jiffies 4294668108
> > #   hex dump (first 8 bytes):
> > #     00 00 d0 02 81 88 ff ff                          ........
> > #   backtrace (crc 6c1bc6d6):
> > #     __kmalloc_noprof+0x56b/0x830
> > #     futex_init+0x108/0x3c0
> > #     do_one_initcall+0xc3/0x4b0
> > #     do_initcalls+0x215/0x240
> > #     kernel_init_freeable+0x4a1/0x530
> > #     kernel_init+0x18/0x180
> > #     ret_from_fork+0x547/0x870
> > #     ret_from_fork_asm+0x1a/0x30
> > not ok 13 selftests: damon: sysfs_memcg_path_leak.sh # exit=1
> 
> I have no idea what DAMON does or what this selftest is on about. SJ?

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.

    # echo scan > /sys/kernel/debug/kmemleak
    # cat /sys/kernel/debug/kmemleak
    unreferenced object 0xffff888140f848d0 (size 16):
      comm "swapper/0", pid 1, jiffies 4294892369
      hex dump (first 16 bytes):
        00 00 fd 40 81 88 ff ff 00 00 25 80 81 88 ff ff  ...@......%.....
      backtrace (crc 1f413cd3):
        __kmalloc_noprof+0x446/0x590
        futex_init+0x99/0x230
        do_one_initcall+0x5c/0x300
        kernel_init_freeable+0x23f/0x2c0
        kernel_init+0x1a/0x130
        ret_from_fork+0x230/0x2f0
        ret_from_fork_asm+0x1a/0x30

So, the commit is not breaking DAMON.  But apparently it is leaking something.

Sorry for making the confusing noise.  I will update the test to not fail for
non-DAMON leak.

FYI, the 'decode_stacktrace.sh' output is like below:

    unreferenced object 0xffff888140f848d0 (size 16):
    comm "swapper/0", pid 1, jiffies 4294892369
    hex dump (first 16 bytes):
    00 00 fd 40 81 88 ff ff 00 00 25 80 81 88 ff ff  ...@......%.....
    backtrace (crc 1f413cd3):
    __kmalloc_noprof (include/linux/kmemleak.h:44 mm/slub.c:4625 mm/slub.c:4945 mm/slub.c:5361 mm/slub.c:5387)
    futex_init (include/linux/slab.h:973 include/linux/slab.h:1189 kernel/futex/core.c:2024)
    do_one_initcall (init/main.c:1347)
    kernel_init_freeable (init/main.c:1409 (discriminator 1) init/main.c:1425 (discriminator 1) init/main.c:1445 (discriminator 1) init/main.c:1658 (discriminator 1))
    kernel_init (init/main.c:1548)
    ret_from_fork (arch/x86/kernel/process.c:158)
    ret_from_fork_asm (arch/x86/entry/entry_64.S:245)

[1] b78b0b658252 ("futex: Use runtime constants for __futex_hash() hot path")


Thanks,
SJ

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

[Peter Zijlstra]

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

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

[Catalin Marinas]

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