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.

Reply via email to