Re: [PATCH v2] mm: kmemleak: scan modified objects as soon as they are grayed

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 30 Oct 2026 11:31:10 -0700 Breno Leitao <leitao@debian.org> wrote:

> kmemleak keeps reporting the guard page of a systemd-journald thread
> stack on Meta's debug kernels, even with min_unref_scans set:
> 
>   unreferenced object 0xffff88829a30ae40 (size 256):
>     comm "systemd-journal", pid 961, jiffies 4294814590
>     backtrace (crc 49b3881c):
>       kmem_cache_alloc_noprof+0x2ee/0x630
>       vm_area_dup+0x36/0x750
>       __split_vma+0xef/0x7d0
>       vma_modify+0x11c3/0x18a0
>       vma_modify_flags+0x1ea/0x2a0
>       mprotect_fixup+0x249/0x630
>       do_mprotect_pkey+0x531/0x820
>       __x64_sys_mprotect+0x7c/0x90
> 
> The VMA is still mapped. It was never faulted in, so it has no anon_vma
> and no file, and the only pointer to it is a slot in a maple tree leaf.
> The mm tree runs in RCU mode: every write replaces the leaf with a copy
> and frees the old one after a grace period. journald rewrites its tree
> every couple of seconds, while a scan on a large debug host takes many
> minutes, so the leaf kmemleak queued is freed before its turn, and the
> copy that replaced it was linked after its parent had been scanned.
> 
> The pass over modified objects is meant to catch such moved references,
> and the new leaf, being a new white object, does get grayed there.
> 
> But the gray list is only scanned after the whole object_list walk, and
> by then that copy has been replaced and freed as well. The confirmation
> scan has no such pass, so the miss repeats round after round no matter
> how many consecutive scans are required.
> 
> Scan the gray list during the walk instead, within a jiffy of an object
> being grayed. Do it from a variant of kmemleak_cond_resched(), which
> already pins the current object while the RCU read lock is dropped. The
> live leaf is then read shortly after the walk reaches it, before it can
> be freed.
> 
> Scanning the gray list after every grayed object made a full scan 41%
> slower (1.72s -> 2.42s, arm64 guest with lockdep) when the pass grays a
> million objects that do not point to each other. Scanning it at most
> once a jiffy keeps that at the baseline, leaves idle, file storm and
> mmap churn workloads unchanged, and still removes the false positives
> at HZ=100.

Thanks.  I'm thinking

Fixes: 04609ccc40c4 ("kmemleak: Reduce the false positives by checking for modified objects")
cc:stable

Agreed?