From: Catalin Marinas <catalin.marinas@arm.com>
To: Breno Leitao <leitao@debian.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Shuah Khan <shuah@kernel.org>,
workflows@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-kselftest@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH 1/2] mm/kmemleak: report leaks only after N consecutive unreferenced scans
Date: Thu, 2 Jul 2026 08:49:42 +0100 [thread overview]
Message-ID: <akYYFpyU5Fc-ubUw@arm.com> (raw)
In-Reply-To: <20260626-kmemleak_twice-v1-1-ab28f7cc0971@debian.org>
On Fri, Jun 26, 2026 at 08:52:02AM -0700, Breno Leitao wrote:
> kmemleak reports an object the first scan it is found unreferenced. Its
> mark phase runs without stopping the rest of the kernel and without a
> write barrier, so a live object whose only reference is briefly invisible
> during a concurrent RCU update -- e.g. a VMA moved between maple tree
> nodes, or a page-cache xa_node -- can be seen as unreferenced for that one
> scan. Because an object is flagged as reported only once, such a transient
> race turns into a permanent false positive.
>
> Track how many consecutive scans each object has been seen unreferenced
> and only report it once that reaches min_unref_scans, a new module
> parameter. It defaults to 1, leaving the behaviour unchanged; setting it
> higher (e.g. 2) still reports a genuine leak, one scan later, while an
> object referenced again before the threshold restarts its run and is never
> reported.
>
> min_unref_scans can be set at boot with kmemleak.min_unref_scans=<n> or at
> run-time via /sys/module/kmemleak/parameters/min_unref_scans.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
It looks like a good addition to me. All objects require a second pass
initially to get their checksum updated but that's not sufficient when
they are moved between nodes without having their content changed (list
in a linked list).
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 7c7ba17ce7af0..5b14ccb36f95b 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -151,6 +151,8 @@ struct kmemleak_object {
> int min_count;
> /* the total number of pointers found pointing to this object */
> int count;
> + /* consecutive scans the object has been seen unreferenced */
> + unsigned int unref_scans;
> /* checksum for detecting modified objects */
> u32 checksum;
> depot_stack_handle_t trace_handle;
> @@ -232,6 +234,9 @@ static unsigned long max_percpu_addr;
> static struct task_struct *scan_thread;
> /* used to avoid reporting of recently allocated objects */
> static unsigned long jiffies_min_age;
> +/* consecutive scans an object must stay unreferenced before reporting */
> +static unsigned int min_unref_scans = 1;
> +module_param(min_unref_scans, uint, 0644);
0644 is fine. Not sure why kmemleak_verbose was 0600.
--
Catalin
next prev parent reply other threads:[~2026-07-02 7:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 15:52 [PATCH 0/2] mm/kmemleak: add min_unref_scans to suppress transient false positives Breno Leitao
2026-06-26 15:52 ` [PATCH 1/2] mm/kmemleak: report leaks only after N consecutive unreferenced scans Breno Leitao
2026-07-02 7:49 ` Catalin Marinas [this message]
2026-06-26 15:52 ` [PATCH 2/2] selftests/mm: test kmemleak's N-consecutive-scan leak confirmation Breno Leitao
2026-07-02 8:41 ` Catalin Marinas
2026-07-02 14:55 ` Breno Leitao
2026-07-03 11:24 ` Breno Leitao
2026-07-03 14:55 ` Catalin Marinas
2026-07-03 15:43 ` Breno Leitao
2026-07-03 17:11 ` Breno Leitao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=akYYFpyU5Fc-ubUw@arm.com \
--to=catalin.marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=david@kernel.org \
--cc=kernel-team@meta.com \
--cc=leitao@debian.org \
--cc=liam@infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.