I have kmemleak on some test tiers to find memory leaks in my fleet, with the reports dumped to dmesg (CONFIG_DEBUG_KMEMLEAK_VERBOSE set). It works super well.
The problem I have is some false positives that show up from time to time and go away on a subsequent scan. Something transiently unreferenced -- whose only reference is briefly invisible during a concurrent RCU update, e.g. a VMA moving between maple-tree nodes, or a page-cache xa_node -- is seen as unreferenced for a single scan and reported as a leak that does not exist. This series adds a min_unref_scans module parameter requiring an object to stay unreferenced across that many consecutive scans before it is reported. Basically it is a trade-off between report latency and reliability (false-positiveness?). It defaults to 1 (the unchanged report-on-first-scan behaviour) and, set to 2 or more, filters these single-scan races while still reporting genuine leaks one scan later. Would it be acceptable upstream? Patch 1 implements it; patch 2 adds an mm selftest that drives the parameter via samples/kmemleak, in case this is useful. Signed-off-by: Breno Leitao <[email protected]> --- Breno Leitao (2): mm/kmemleak: report leaks only after N consecutive unreferenced scans selftests/mm: test kmemleak's N-consecutive-scan leak confirmation Documentation/dev-tools/kmemleak.rst | 8 ++ mm/kmemleak.c | 14 ++- tools/testing/selftests/mm/Makefile | 1 + .../testing/selftests/mm/ksft_kmemleak_confirm.sh | 111 +++++++++++++++++++++ 4 files changed, 132 insertions(+), 2 deletions(-) --- base-commit: 30ffa8de54e5cc80d93fd211ca134d1764a7011f change-id: 20260626-kmemleak_twice-ed01218aeccb Best regards, -- Breno Leitao <[email protected]>
