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

[Breno Leitao <leitao@debian.org>]

Hello Catalin,

On Mon, Oct 19, 2026 at 04:56:53PM +0100, Catalin Marinas wrote:
> > @@ -1981,8 +1985,13 @@ static int __kmemleak_scan(bool full)
> >  	 */
> >  	rcu_read_lock();
> >  	list_for_each_entry_rcu(object, &object_list, object_list) {
> > -		if (need_resched())
> > -			kmemleak_cond_resched(object);
> > +		/*
> > +		 * Scan newly grayed objects now, not after the walk: one may
> > +		 * hold the only reference to another and be freed by then,
> > +		 * like a maple tree node that keeps being replaced.
> > +		 */
> > +		if (need_resched() || !list_empty(&gray_list))
> > +			kmemleak_cond_resched(object, true);
> 
> I think that's a good way to reduce the false positives for such maple
> tree scenario.

I've created a reproducer [1] for these common false positives I've been
seeing, and this fix removes the false positives.

Link: https://github.com/leitao/linux/commit/1291579c487303c5ffbea2cf532649d26329c8a9 [1]

> Do you have any numbers on how much this extends the scan
> time by?

It doens't seem to extend much, from my quick test, and I am more than
happy to test more:

    workload                     base     patch
    idle                         526ms    527ms
    tmpfs file storm + 1M VMAs   10.78s   11.04s
    mmap/munmap churn + 1M VMAs  4.61s    4.67s
    guard page reproducer        13.46s   13.69s
    100k unrelated objects       672ms    738ms


> If it's too expensive, we could rate-limit it, say every jiffy.

Yea, we can rate-limit it. Do you want to see it now as part of v2 ?

> > @@ -2082,7 +2091,7 @@ static void kmemleak_scan(void)
> >  		bool dedup_print;
> >  
> >  		if (need_resched())
> > -			kmemleak_cond_resched(object);
> > +			kmemleak_cond_resched(object, false);
> 
> Nitpick: instead of passing 'false' in a few places, rename
> kmemleak_cond_resched() to kmemleak_resched_drain() (well, some better
> name) call get kmemleak_cond_resched() to call that with 'false'. We
> could also move need_resched() in such function, being a small wrapper
> the compiler should inline it.

Very good idea, let me respin this patch with your suggestion!

Thanks for the review,
--breno