On Thu, 17 Sep 2026 06:47:37 -0700 Breno Leitao <[email protected]> wrote:
> CONFIG_DEBUG_KMEMLEAK_VERBOSE sends every report to the console, so a > transient false positive there is broadcast to whatever collects the > kernel log rather than sitting in the debugfs file until someone looks. > That asymmetry justifies being more conservative than the general case. > > Require one more consecutive unreferenced scan before reporting. The > only cost is that a genuine leak is reported one scan interval later > (600s by default); the value stays writable at run time through the > module parameter. > > Kernels without CONFIG_DEBUG_KMEMLEAK_VERBOSE keep reporting on the > first unreferenced scan. > > I've been running constant upstream kernel with > CONFIG_DEBUG_KMEMLEAK_VERBOSE set, and I am still seeing some rare false > positive, that goes away with min_unref_scans=3, so, making it the > default based on my heuristic. I'm guessing going from 2 to 3 reduces the false-positive reporting rate, but they're still possible. It all sounds rather rubbery. Why do these false positives occur, anyway? Are we papering over a fundamental problem by filtering out its user-visible effects?
