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(-)
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 <leitao@debian.org>
---
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/20260421-kmemleak_dedup-v1-0-65e31c6cdf0c@debian.org
---
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 <leitao@debian.org>
On Fri, 24 Apr 2026 08:03:35 -0700 Breno Leitao <leitao@debian.org> wrote: > 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. AI review likes the kernel patch but worries about the selftest: https://sashiko.dev/#/patchset/20260424-kmemleak_dedup-v2-0-8bea649b2a92@debian.org
On Fri, Apr 24, 2026 at 10:30:16AM -0700, Andrew Morton wrote: > On Fri, 24 Apr 2026 08:03:35 -0700 Breno Leitao <leitao@debian.org> wrote: > > AI review likes the kernel patch but worries about the selftest: > https://sashiko.dev/#/patchset/20260424-kmemleak_dedup-v2-0-8bea649b2a92@debian.org Ack! I will address then and respin, thanks for raising it. --breno
© 2016 - 2026 Red Hat, Inc.