hello Geert, On Mon, Jul 13, 2026 at 02:36:30PM +0200, Geert Uytterhoeven wrote: > On Mon, 13 Jul 2026 at 13:48, Breno Leitao <[email protected]> wrote: > > From: Catalin Marinas <[email protected]> > > > > The kmemleak marking phase is not atomic. While the object graph is > > traversed, the kernel can modify pointers, free objects or allocate new > > ones. If a reference to an object is moved from one location to another, > > kmemleak scanning may miss it. We have explicit annotations like > > kmemleak_transient_leak() but identifying and maintaining them is not > > trivial. > > > > Given that such transient leaks are short-lived, rather than just > > reporting such objects as leaks, do another scan to confirm the > > suspected objects. If no new leaks are found during the first scan, skip > > the confirmation one. > > > > Signed-off-by: Catalin Marinas <[email protected]> > > Assisted-by: Claude:claude-opus-4-8 > > Signed-off-by: Breno Leitao <[email protected]> > > Cc: Andrew Morton <[email protected]> > > Thanks for your patch! > > For how long does this postpone the reporting of a real leak?
No, it doesn't postpone leak reporting by default. The default behavior remains unchanged. This patchset introduces two features. The first (patch 1) performs an immediate rescan within each scan cycle when potential leaks are detected, filtering out transient leaks. Each scan takes slightly longer, but a single scan cycle now detects and reports leaks with fewer false positives. The second feature adds 'min_unref_scans' (defaulting to 1), which only reports a leak after it appears unreferenced across min_unref_scans consecutive scans. With the default configuration (min_unref_scans=1), a single scan will still report your leak. if you change it to 2, then, the leak will only be reported if the leak is detected by two scans --breno
