From: Breno Leitao <leitao@debian.org>
To: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Shuah Khan <shuah@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
"Liam R. Howlett" <liam@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-kselftest@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v3 1/2] mm/kmemleak: dedupe verbose scan output by allocation backtrace
Date: Tue, 30 Jun 2026 01:43:16 -0700 [thread overview]
Message-ID: <akOAzZkWRzQtIeyI@gmail.com> (raw)
In-Reply-To: <20260506-kmemleak_dedup-v3-1-2d36aafc34da@debian.org>
On Wed, May 06, 2026 at 05:58:24AM -0700, Breno Leitao wrote:
> Dedupe within each scan using stackdepot's trace_handle as the key: for
> every leaked object with a recorded stack trace, look up the
> representative kmemleak_object in a per-scan xarray keyed by
> trace_handle.
Just to circle back to this patch that now it is upstream and deployed to
production.
I've got this feature enabled in Meta's kernel "debug" tier (which runs with
kmemleak enabled), and this is being very helpful. For instance, this is the
kmemleak reports (instead of 330 similar reports).
kmemleak: unreferenced object 0xffff0000c3b5ca00 (size 96):
kmemleak: comm "swapper/0", pid 1, jiffies 4294748185
kmemleak: backtrace (crc 22d8f576):
kmemleak: kmemleak_alloc+0x3c/0xc8
kmemleak: __kmalloc_node_noprof+0x42c/0x7c0
kmemleak: __alloc+0x160/0x3a8
kmemleak: alloc_bulk+0x3d8/0x7b0
kmemleak: bpf_mem_alloc_init+0x3f8/0xd48
kmemleak: cpumask_kfunc_init+0x88/0x158
kmemleak: __initstub__kmod_cpumask__654_534_cpumask_kfunc_init7+0x14/0x28
kmemleak: do_one_initcall+0xe0/0x9f8
kmemleak: do_initcall_level+0x12c/0x1d0
kmemleak: do_initcalls+0x60/0x108
kmemleak: do_basic_setup+0x80/0x98
kmemleak: kernel_init_freeable+0x280/0x400
kmemleak: kernel_init+0x24/0x170
kmemleak: ret_from_fork+0x10/0x20
kmemleak: ... and 1 more object(s) with the same backtrace
kmemleak: unreferenced object 0xffff0000c3b57080 (size 96):
kmemleak: comm "hardirq", pid 0, jiffies 4298468258
kmemleak: backtrace (crc 85619951):
kmemleak: kmemleak_alloc+0x3c/0xc8
kmemleak: __kmalloc_node_noprof+0x42c/0x7c0
kmemleak: __alloc+0x160/0x3a8
kmemleak: alloc_bulk+0x3d8/0x7b0
kmemleak: bpf_mem_refill+0xb4/0x8a0
kmemleak: irq_work_single+0x9c/0x178
kmemleak: irq_work_run+0x12c/0x208
kmemleak: ipi_handler+0x1cc/0x900
kmemleak: handle_percpu_devid_irq+0x3bc/0x4f8
kmemleak: generic_handle_domain_irq+0xa0/0x100
kmemleak: gic_handle_irq+0x364/0x688
kmemleak: ... and 331 more object(s) with the same backtrace
I've haven't investigate the leak itself, and that is not the reason of this
email, it is just to share that this is being quite useful at real production
environments.
next prev parent reply other threads:[~2026-06-30 8:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-06 12:58 [PATCH v3 0/2] mm/kmemleak: dedupe verbose scan output Breno Leitao
2026-05-06 12:58 ` [PATCH v3 1/2] mm/kmemleak: dedupe verbose scan output by allocation backtrace Breno Leitao
2026-06-30 8:43 ` Breno Leitao [this message]
2026-05-06 12:58 ` [PATCH v3 2/2] selftests/mm: add kmemleak verbose dedup test Breno Leitao
2026-05-08 22:17 ` [PATCH v3 0/2] mm/kmemleak: dedupe verbose scan output Andrew Morton
2026-05-11 15:41 ` Breno Leitao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=akOAzZkWRzQtIeyI@gmail.com \
--to=leitao@debian.org \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=kernel-team@meta.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox