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@xxxxxxxxxxxxx> 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@xxxxxxxxx>
> > | Closes: https://lore.kernel.org/oe-lkp/202608071053.6db6276e-lkp@xxxxxxxxx
> > 
> > 
> > # 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