I am starting to run with kmemleak in verbose enabled in some "probe points" across the my employers fleet so that suspected leaks land in dmesg without needing a separate read of /sys/kernel/debug/kmemleak.
The downside is that workloads which leak many objects from a single allocation site flood the console with byte-for-byte identical backtraces. Hundreds of duplicates per scan are common, drowning out distinct leaks and unrelated kernel messages, while adding no signal beyond the first occurrence. This series collapses those duplicates inside kmemleak itself. Each unique stackdepot trace_handle prints once per scan, followed by a short summary line when more than one object shares it: kmemleak: unreferenced object 0xff110001083beb00 (size 192): kmemleak: comm "modprobe", pid 974, jiffies 4294754196 kmemleak: ... kmemleak: backtrace (crc 6f361828): kmemleak: __kmalloc_cache_noprof+0x1af/0x650 kmemleak: ... kmemleak: ... and 71 more object(s) with the same backtrace The "N new suspected memory leaks" tally and the contents of /sys/kernel/debug/kmemleak are unchanged - the per-object detail is still available on demand, only the verbose (dmesg) output is collapsed. Patch 1 is the kmemleak change. Patch 2 adds a selftest that loads samples/kmemleak's CONFIG_SAMPLE kmemleak-test module to generate ten leaks sharing one call site and checks that the printed count is strictly less than the reported leak total. Not sure if Patch 2 is useful or not, if not, it is easier to discard. Breno Leitao (2): mm/kmemleak: dedupe verbose scan output by allocation backtrace selftests/mm: add kmemleak verbose dedup test mm/kmemleak.c | 102 +++++++++++++++++- .../selftests/mm/test_kmemleak_dedup.sh | 78 ++++++++++++++ 2 files changed, 175 insertions(+), 5 deletions(-) create mode 100755 tools/testing/selftests/mm/test_kmemleak_dedup.sh -- 2.52.0 Signed-off-by: Breno Leitao <[email protected]> --- Changes in v2: - Drop struct kmemleak_dedup_entry and its kmalloc. (Catalin) - Handle trace_handle == 0 instead of dropping it. - Skip hex dump for coalesced entries (dup_count > 1) — bytes would differ across objects sharing a trace anyway, and it removes the only object->pointer read left in the deferred path. - Counter narrowed from unsigned long count to unsigned int dup_count. - Link to v1: https://patch.msgid.link/[email protected] --- Breno Leitao (2): mm/kmemleak: dedupe verbose scan output by allocation backtrace selftests/mm: add kmemleak verbose dedup test mm/kmemleak.c | 148 ++++++++++++++++++++-- tools/testing/selftests/mm/Makefile | 1 + tools/testing/selftests/mm/ksft_kmemleak_dedup.sh | 86 +++++++++++++ 3 files changed, 227 insertions(+), 8 deletions(-) --- base-commit: 4c406406070d57dbefeaad149181785330c23f92 change-id: 20260420-kmemleak_dedup-bee54ffa65e7 Best regards, -- Breno Leitao <[email protected]>
