From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (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 C4FF83EEAFF for ; Wed, 20 May 2026 15:00:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=96.67.55.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779289241; cv=none; b=h9XUFQV01zmOpe2Kp1sCM8LchPLd47xps+/CFkEs5/Qp115uiRDINi90SR6wnlvx27hpKhqR/6n33pdnvZ6kUMGeXMm2S/eeLPGViD2U6Z43mKVz7bEVt9/ZG7Fowp09tosEjkkezvtSsVlGIGd0CszYwdRHyUHtdq2tDaVgwSk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779289241; c=relaxed/simple; bh=UwwuIzTzhgzjMlX2GxOnbYg2TVk0j9izsbPvHwhUwbs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FY1xn2rZwHW3To/JuhoCnB3NnEDvcb1m56/jgP9JVzBoxvvryC/uOaLpV6CxemcXkUFjaHcnBV28QyQPOVD5Dek0H7HYd3lhmOLQS/9Wzs6y8me0jPbN6Hlt9c/q3gXEbeyRzy0WHNgXItlRbekDvTnNy+p0lLCqtwBb9orTdWE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com; spf=pass smtp.mailfrom=surriel.com; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b=hvoqZOeC; arc=none smtp.client-ip=96.67.55.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=surriel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=surriel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=surriel.com header.i=@surriel.com header.b="hvoqZOeC" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=surriel.com ; s=mail; h=Content-Transfer-Encoding:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:Content-Type:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=1c9ByeJjCfG0gYJvGtiXQ9M/uTq5YaBvLV18O1MJ0UU=; b=hvoqZOeCLBvtxCldkLZmtJCI3C vkbEdJDYrqh8kpeznCytOLOHIZOliqZlJyNZbgbxYe91iqQkd2biXISW8EiEczS2hLPuiRbopm408 cEYPlcyvs/1U0hI+iKCAPqZhgvTI2uNjuy0kE3004UXGzZAYuVE0VmGf6aRFD1/lpfRuMIKng/FKK hWwPc1X3+5iC5BNoE4Xg9gPCUxhdvrMe+LiuifKYFS4pf+ePmN+Q85nGCEnQpzm3gZRtlRQ/FYzrF Nha6i8e55ePs8+CWc2bnIoi7AcPruD0KOBeJL4Xzi0zb2Ps7NOkw3x9qsIMrLvw5awqMD1QlOrJf5 I0DCVcYg==; Received: from fangorn.home.surriel.com ([10.0.13.7]) by shelob.surriel.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1wPiPM-0000000024Q-0T4O; Wed, 20 May 2026 11:00:28 -0400 From: Rik van Riel To: linux-kernel@vger.kernel.org Cc: kernel-team@meta.com, linux-mm@kvack.org, david@kernel.org, willy@infradead.org, surenb@google.com, hannes@cmpxchg.org, ljs@kernel.org, ziy@nvidia.com, usama.arif@linux.dev, fvdl@google.com, Rik van Riel Subject: [RFC PATCH 04/40] mm: mm_init: fix zone assignment for pages in unavailable ranges Date: Wed, 20 May 2026 10:59:10 -0400 Message-ID: <20260520150018.2491267-5-riel@surriel.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260520150018.2491267-1-riel@surriel.com> References: <20260520150018.2491267-1-riel@surriel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit init_unavailable_range() initializes struct pages for memory holes between memblock regions. It receives a zone ID from its caller, but that zone ID is simply the last zone processed in memmap_init()'s iteration -- it does not necessarily match the zone that actually spans each PFN in the hole. When an unavailable range straddles a zone boundary (e.g. a hole between DMA32 and Normal), all pages in the hole get tagged with the wrong zone in page->flags. Any later page_zone() call on such a page returns the wrong zone, which can cause accounting confusion or crashes when code assumes the returned zone is valid for that page. Fix by looking up the correct zone for each PFN in the hole. This is init- only code running once at boot, so the per-page zone lookup has no performance impact. Signed-off-by: Rik van Riel Assisted-by: Claude:claude-opus-4.7 syzkaller --- mm/mm_init.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/mm/mm_init.c b/mm/mm_init.c index 1bc909da9c13..47a222e49fc9 100644 --- a/mm/mm_init.c +++ b/mm/mm_init.c @@ -834,9 +834,27 @@ static void __init init_unavailable_range(unsigned long spfn, { unsigned long pfn; u64 pgcnt = 0; + pg_data_t *pgdat = NODE_DATA(node); + int zid = zone; for_each_valid_pfn(pfn, spfn, epfn) { - __init_single_page(pfn_to_page(pfn), pfn, zone, node); + /* + * The caller's zone may not match the PFN when unavailable + * ranges straddle zone boundaries. Look up the correct zone + * so page->flags encodes the right zone for page_zone(). + */ + if (!zone_spans_pfn(&pgdat->node_zones[zid], pfn)) { + int z; + + for (z = 0; z < MAX_NR_ZONES; z++) { + if (zone_spans_pfn(&pgdat->node_zones[z], pfn)) { + zid = z; + break; + } + } + } + + __init_single_page(pfn_to_page(pfn), pfn, zid, node); __SetPageReserved(pfn_to_page(pfn)); pgcnt++; } -- 2.54.0