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 A40B027E07E for ; Fri, 10 Jul 2026 08:51:48 +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=1783673510; cv=none; b=Wxi3MFFv+KiUU09c/7UwY1L9n7Bep8xZQGekBIu4LFrwoZIXLEp1GR6UQkcOqAJ1lgKjhxgz9s5K4e67XqSpz8T9tIUvXqYDuJ4QkvOowgH9G/gc8HwB9aTbiA8GkG1jnNSQ28upOa4+tdvsB6/oFGG+Ec69hqpg+LK1Vasebxc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783673510; c=relaxed/simple; bh=2aPuHgrx9qVBZm1U79LpB4JMKA8PsGS/5/vQ6bsOGhg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ks0XneQ4roZD575VSYW009wj1xid2rwrG14XNsKraCq/XSOWFKraetuwBz06+y3UzanMU3iGVypl8Rf6rDYqZcx1aHPYWQcRRrzZYUSArMJ/5JkbDbWQvpFWw2cCmu4l1yCJ55z9j6as/o6NDVkbPqwAjk8TdWT1kZ/2oVuebro= 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=gfurfvAY; 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="gfurfvAY" 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=3FuP1eMVNk9mkgmdOifxmzFZMlk1+U1DrobeqWEeEQU=; b=gfurfvAYcWbyKsomW4JufEF/rJ ahzc8mqteKkRBc1IM1pOlveeF0PkaEf9I6dLtUfche17t3WNsIrTbaQ+4+QHWlBCysr35OkckOy6B 0qL7jHhdESb4RcsNBFV9IDVOVTaFfZow1x+dUxRXVNspqEBCasOGCrgeUM/5/iGEPjA027tV/qm/R jwStVcf2DhYiI/aRgwJJxQdzWesLkYmvn/Yc2zpEfhjVuFWFwmqZX5PQbYGE82i23VyhcDp7fMB4P AjxYrhOE+U4bROGfMYkiO91dBdlUXaAuRxZCl7lJlR0tiZAiiRuG3qCIK+uVoCN2pbI0ifKszhwFg JNgCwpLw==; 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 1wi6xT-004MUP-2X; Fri, 10 Jul 2026 08:51:44 +0000 Date: Fri, 10 Jul 2026 01:51:40 -0700 From: Breno Leitao To: Catalin Marinas Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [PATCH] mm: kmemleak: confirm suspected leaks with a second scan Message-ID: References: <20260709173347.689607-1-catalin.marinas@arm.com> 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: <20260709173347.689607-1-catalin.marinas@arm.com> X-Debian-User: leitao On Thu, Jul 09, 2026 at 06:24:47PM +0100, Catalin Marinas wrote: > The kmemleak marking phase is not atomic. While the object graph is > traversed, the kernel can modify pointers, free objects or allocate new > ones. If a reference to an object is moved from one location to another, > kmemleak scanning may miss it. We have explicit annotations like > kmemleak_transient_leak() but identifying and maintaining them is not > trivial. > > Given that such transient leaks are short-lived, rather than just > reporting such objects as leaks, do another scan to confirm the > suspected objects. If no new leaks are found during the first scan, skip > the confirmation one. > > Signed-off-by: Catalin Marinas > Assisted-by: Claude:claude-opus-4-8 > Cc: Breno Leitao > Cc: Andrew Morton Tested-by: Breno Leitao Reviewed-by: Breno Leitao PS: This is now conflicting with commit 946935b07cc94 ("mm/kmemleak: skip the remaining scan phases when interrupted"), which has just showed up in linux-next. So, a respin might be required. > BTW, I'll be away from Saturday for three weeks. I may reply > occasionally but won't be able to test anything. Let me know if you want me to respin it based on linux-next. BTW: Really thanks for doing it. I will backport it to Meta's kernel to pressure-test it and keep an eye on false positives. --breno