On Fri, 24 Apr 2026 08:03:35 -0700 Breno Leitao <[email protected]> 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/[email protected]
