From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 BEE2C2E974D for ; Fri, 10 Jul 2026 03:13:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783653184; cv=none; b=bHj+CdkzRX8lNdK+V4LyWyZ6Zfelr0oZOHvFWb9H1FC+tG2M6zMVOHj1SpJLysI3OV1XYSFTVXyPERfkQNN4yGUiyDX/x4BmcBfc9+1Xl7yVkeC8gAZRlpL1WJRXuGm7uVFs3LgjOKFbBer7B3RyEaBObSd5zLuDRlfH8LjJjjw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783653184; c=relaxed/simple; bh=KwQD3Kk1m/DNprmyFRxCsu44wMXW5d6S/gbYK56C0lQ=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=M1ND6uLqjFWPQmkCgvjlvv1YaS47J/8TBfFW0lHsg6loFbInkJrKuxEq1L7uVwknVcV7Z/4billj3iotFWQJqc5Mdh9QQEPMkTZK/1vymGDQ4o5QgK/aEArKkh4KcMmRgSoosWBaHvJoXAw2xswXlDFOpoK6BGMoU8rrNN8Fdao= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=ApP0SeYW; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="ApP0SeYW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21E841F000E9; Fri, 10 Jul 2026 03:13:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1783653183; bh=zbHaVsaTwyP/6PLrtHwV2B05KJtv8UaJpsbVL8wi2eA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ApP0SeYWgK/fb+hUNWApFldDRqoVoZWnQdYp+98Eoot66+GQ/gZq0cnbbDL/XwvgE V3W1g9IjjTYwLb3QcQeVGTy5qEjGi6EvCW676uRYlp4bbbITuIEuQ0F1C5S1YAO6ej 1wByCOxQX/KIo/QAyip+SmkItJm8arBhWSgt7ZL0= Date: Thu, 9 Jul 2026 20:13:02 -0700 From: Andrew Morton To: Catalin Marinas Cc: leitao@debian.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: kmemleak: confirm suspected leaks with a second scan Message-Id: <20260709201302.fb87e3bc6b2822c56856e455@linux-foundation.org> In-Reply-To: <20260709173347.689607-1-catalin.marinas@arm.com> References: <20260709173347.689607-1-catalin.marinas@arm.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Thu, 9 Jul 2026 18:24:47 +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. All sort of build errors here due to other changes which are queued in mm.git. > BTW, I'll be away from Saturday for three weeks. I may reply > occasionally but won't be able to test anything. Have a great time - we'll be here when you get back.