Re: kmemleak handling of kfree_rcu

[Catalin Marinas <catalin.marinas@arm.com>]

On Tue, Sep 05, 2023 at 02:22:13PM -0700, Christoph Paasch wrote:
> On Sep 4, 2023, at 2:22 PM, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > Not sure which RCU variant you are using but most likely the false
> > positives are caused by the original reference to the object being lost
> > and the pointer added to a new location that kmemleak does not track
> > (e.g. bnode->records[] in the tree-based variant).
> > 
> > A quick attempt (untested, not even compiled):
> 
> I tried out your patch. It does resolve the false positive !
> 
> However, I am occasionally getting a report of a single object being
> leaked. When I try to visualize it with `cat
> /sys/kernel/debug/kmemleak`, the object does not show up anymore…

How often do you trigger the scanning? Since kmemleak does not stop the
world (as some garbage collectors do), there's potential for false
positives (e.g. a reference to it is in a register on some CPU while
being moved from one list to another). The heuristics employed for this
is to checksum the object and only report if the checksum has not
changed in successive scans. But this is still problematic if scanning
is done quickly in succession. The default 10min scanning (even 1min)
shouldn't be an issue.

I had a plan to do a "stop_scan" option (using stop_machine) but never
got the time to do this.

> If you have an updated patch, let me know. I can test it.

I sent it in reply to Joel.

Thanks.

-- 
Catalin