All of lore.kernel.org
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 Jared Kangas <jkangas@redhat.com>,
	willy@infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] radix tree: fix kmemleak false positive in radix_tree_shrink()
Date: Mon, 6 Jul 2026 03:36:04 -0700	[thread overview]
Message-ID: <akuD2GA_l8zgcb81@gmail.com> (raw)
In-Reply-To: <aCyI8T2sWlPLEYZ_@arm.com>

Hello Catalin,

On Tue, May 20, 2025 at 02:51:45PM +0100, Catalin Marinas wrote:
> That said, the current logic updates the checksum when it was found
> unreferenced (potential leak). If the object was referenced in
> subsequent scans, the checksum remains intact, so minutes later it may
> be seen again as a transient leak. Something like below should reduce
> the transient leak reports (though not eliminate):
> 
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index c12cef3eeb32..b1460c64f4b1 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -1408,6 +1408,12 @@ static void update_refs(struct kmemleak_object *object)
>  		/* put_object() called when removing from gray_list */
>  		WARN_ON(!get_object(object));
>  		list_add_tail(&object->gray_list, &gray_list);
> +		/*
> +		 * Reset the checksum; the object must be unchanged between
> +		 * two consecutive scans where it was unreferenced
> +		 * (color_white()) in order to be reported as a leak.
> +		 */
> +		object->checksum = 0;

I noticed this patch never made it upstream. While I understand it's
related to min_unref_scans, I think it still makes sense given that
min_unref_scans defaults to 1.

Your proposal provides an additional mechanism to reduce false
positives, which aligns with my current work in this area.

      reply	other threads:[~2026-07-06 10:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-14 18:01 [PATCH] radix tree: fix kmemleak false positive in radix_tree_shrink() Jared Kangas
2025-05-14 22:16 ` Andrew Morton
2025-05-15 21:23   ` Jared Kangas
2025-05-20 13:51   ` Catalin Marinas
2026-07-06 10:36     ` Breno Leitao [this message]

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=akuD2GA_l8zgcb81@gmail.com \
    --to=leitao@debian.org \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=jkangas@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=willy@infradead.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.