From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D53C22E7391 for ; Mon, 6 Jul 2026 10:36:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783334188; cv=none; b=CcZdOaLsJn41CutoFRO5aqaRe7TUNA6WuL+YtviVFhk3Ihrr80NaHzTNPwZbUZnsdmYFCPCmC4+yLztLqe25ECDRGSkxK6quQ6Qx7WLjfOkgo+9xl0O+ZjM5qY0/SziEkeM0Jb47OAHIoHPzczZZcopxmCuttjuUUD+MpCEV+E8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783334188; c=relaxed/simple; bh=NyXBW7Y6ZGPbMZix5GYpD0B3OW7iicIt1DqzG2/N3kM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EiSIoI2utBS8m9G2JGXb2GOAIY77dofjHpd9SRZVIGbxx1sWvz/bvSvgTAQ4vF8ClUN0Cl6svsX+PQthYIVnvpBmEe60gdwwgVsiIBFFtM0HRJ/SOBZDP88C8VPdLdGXAiweDK9foZa20U8UfEz0CjypPs4U6aN84JnPMnUZkOA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=vGE6tXvD; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="vGE6tXvD" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=9crfFwEQbi0iAise/XIOmUGXmsAG61ArUYb5NujbxtQ=; b=vGE6tXvDT1WanUFKKPBj0iTKHh UbUjTZPiw8ql9VCp5okW85civwObuy9m538J/3t30TlL7OyHKWbKcB44wzlhCYULgmjfRqPRK+fBC NGpRnm3Df/jtNnzVm33MGOnUb5KYwD6k5FvXcBRifo5x6Zr53tMq6mMV48zA2ablN+9B2jpQi66QQ bZF/WhdVlFZggn5DM767DuqeAuZdSOcbBJeQyZxIioh1pULXTmo49jPgP3RJjInTL4WmrzYZkA3pD cwsZ4zlKJN8Es+7PSO0htN5NzaV76qaryxxEtstLq0sq1zdkwtpbRhIcGXACVckodBCI+Dcjlkw19 Nswi+GFA==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wgggL-001M3M-1W; Mon, 06 Jul 2026 10:36:09 +0000 Date: Mon, 6 Jul 2026 03:36:04 -0700 From: Breno Leitao To: Catalin Marinas Cc: Andrew Morton , Jared Kangas , willy@infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] radix tree: fix kmemleak false positive in radix_tree_shrink() Message-ID: References: <20250514180137.363929-1-jkangas@redhat.com> <20250514151605.9a07943954737f52e2895b05@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Debian-User: leitao 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.