Re: [PATCH v2 0/2] mm/kmemleak: dedupe verbose scan output

[Andrew Morton]

On Fri, 24 Apr 2026 08:03:35 -0700 Breno Leitao <leitao@xxxxxxxxxx> 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@xxxxxxxxxx