From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) (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 580D33C4553 for ; Fri, 27 Mar 2026 08:14:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774599300; cv=none; b=UXhltwb8Ji+a+vOrnoBIgeJhrTJbK8vOqBUFz92ItbPbWB4FqI2BRqBHODhKTStjfwNT2rdkCThmNISB6Oa5x1GgEIBvcICHUWizNTUwXi8M2CnUn6tCR+3fPIRW5M2+OpcIlLXEsGUq0EInvOg2iti5KsVVIYld6RUoPysGtJM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774599300; c=relaxed/simple; bh=hrA7WX2Hr5pE+ugjkloLKOSMZ7VrDfp3NDi3BU/p94s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=FRchnvo7XACon5FbDbk1uQ6Cvph/XP7PRYo5X1x0ReNFl0eu6nv4yjhdNi4KgRFVmEgEQkGl/V8P3rSGSUjEC7iZ0TifLSUzREK5f9aV2EGARZhGxlHITYH2xVMNk4deGH/CSxcakUZPTFvl/hYGcqYXhZAlAqC8E4b6OQW7bSo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=qUqcA5RC; arc=none smtp.client-ip=95.215.58.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="qUqcA5RC" Message-ID: <772e1ce6-6dda-4b73-9c9d-ff04a383f07e@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1774599295; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kdX9mVgGs0Nkzsg6oIXtp9RiOtkTaiCl0p3MKd6jISU=; b=qUqcA5RCMiYHU72GZ7xO63U6oCVbMuxwt8m+xIoh4kjnZ5JcgTPax8dNmzJv5GtweiTbMy jSKdRWs4kqQyitlPr+sUELIrCo69EwJfUNo1ZDgs8E6eq05cFpKX2Edfz26sI89h1yIn32 UlGCRR0e3Apzw5oEaMf594g8EygTscU= Date: Fri, 27 Mar 2026 16:14:00 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2] mm/alloc_tag: clear codetag for pages allocated before page_ext initialization To: Suren Baghdasaryan , Andrew Morton Cc: Kent Overstreet , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20260326140554.191996-1-hao.ge@linux.dev> <20260326181145.35b559956a45b0efdc9c0450@linux-foundation.org> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Hao Ge In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT Hi Suren On 2026/3/27 09:19, Suren Baghdasaryan wrote: > On Thu, Mar 26, 2026 at 6:11 PM Andrew Morton wrote: >> On Thu, 26 Mar 2026 22:05:54 +0800 Hao Ge wrote: >> >>> Due to initialization ordering, page_ext is allocated and initialized >>> relatively late during boot. Some pages have already been allocated >>> and freed before page_ext becomes available, leaving their codetag >>> uninitialized. >>> >>> A clear example is in init_section_page_ext(): alloc_page_ext() calls >>> kmemleak_alloc(). If the slab cache has no free objects, it falls back >>> to the buddy allocator to allocate memory. However, at this point page_ext >>> is not yet fully initialized, so these newly allocated pages have no >>> codetag set. These pages may later be reclaimed by KASAN, which causes >>> the warning to trigger when they are freed because their codetag ref is >>> still empty. >>> >>> Use a global array to track pages allocated before page_ext is fully >>> initialized. The array size is fixed at 8192 entries, and will emit >>> a warning if this limit is exceeded. When page_ext initialization >>> completes, set their codetag to empty to avoid warnings when they >>> are freed later. >>> >> Thanks. I'll queue this for review and test. >> >> But where will I queue it? > I don't think it's extra urgent. It is visible only when debugging > with CONFIG_MEM_ALLOC_PROFILING_DEBUG. > >>> Fixes: 93d5440ece3c ("alloc_tag: uninline code gated by mem_alloc_profiling_key in page allocator") > Hmm. I'm not sure that's the right patch. Technically the problem > exists once we introduced CONFIG_MEM_ALLOC_PROFILING_DEBUG. I'll > double-check. I believe this should be Fixes: dcfe378c81f72 ("lib: introduce support for page allocation tagging"). Earlier I thought backporting this commit here would be quite involved, but after further consideration, this is indeed the commit being fixed. >> A year ago, so a cc:stable might be needed. >> >>> +#ifdef CONFIG_MEM_ALLOC_PROFILING_DEBUG >> otoh, it appears that the bug only hits with >> CONFIG_MEM_ALLOC_PROFILING_DEBUG=y? If so, I'll add that (important) >> info to the changelog. > Correct, it affects only CONFIG_MEM_ALLOC_PROFILING_DEBUG=y and only > if !mem_profiling_compressed. > >> Do people use CONFIG_MEM_ALLOC_PROFILING_DEBUG much? Is a backport >> really needed? > IMO backport would be good. > >> Either way, it seems that this isn't a very urgent issue so I'm >> inclined to add it to the 7.1-rc1 pile, perhaps with a cc:stable. >> >> Please all share your thoughts with me, thanks. > I'm reviewing and testing the patch and there is a race and a couple > of smaller issues. I'll post a reply later today. Thank you so much for your kind help! I really appreciate it. Thanks Hao