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 93C2C3A2541 for ; Thu, 30 Apr 2026 20:22:49 +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=1777580571; cv=none; b=B41oX3/p9E1qMQFzi9IyyyMSQj1tgXfIeSTy0ZQZ/XfXCuMBocZqZaFJIkukO7pTPlDOfO1CgqCdLTLUGFBd3SQid79ri5iqnL64EHyhpICTcT7r8qHxFHFY6DQlxXtVjlkvzlDWgwEmvui4DoUzv5yzTssMwVhnNMu2Rg8tdms= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777580571; c=relaxed/simple; bh=xgJzWI2AgBKYZ7n4XeAhruLCA5gs508OFOIJpEt2t1o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mPkUlVBx4Z7hE4IO/AuGUWKiyUEuexrtVnzdbX3YATCzPo+9nL44ZtEvqgOD5G6655HDaSo82VEA5oO41CLNMa9gj19ZNhqoj0AWRRRS05XGkL0UyOFFxj49jMDu54SyBpLq3vyEcaI+vbGkM4rDQKQLIdqG/DUSk3YF+2Do3N4= 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=YOvCBOn0; 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="YOvCBOn0" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=surriel.com ; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To: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=6QlCxWH+Y7W9QsBlG/iTMnUBj0keGEMtOuPZJKk1hPQ=; b=YOvCBOn0/Z9zKbBcuslksNs0pY NC7KreDKPX+ruw5dKlBiUiRjpyw2hePSWp7e4JeyyA47RWV570IVvgILwoUbLIs6eH7WOYD2ggfR1 HvswcaW+B1C7OiPN8OV4V0Y9Jn7fozGpejYSuPadWCJGupg0vqOKC2KOKhM57aVXfNBmsRB3U3tm1 BSzK5e6vIDkkq1npK5srjK+uvY5yha2+uH/a8PgX6Vhu5Yx1DJgsLtkFXKDL/uDWsPJRR6XzhwwCb zDc771zbMmrX93TzTX5FF3yf/64rK9jJX9Y+YkEv294YzzGQGAwU9dk6Q2e18IPVgPgxeKJbw32Cn RccK2hGg==; 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 1wIXuC-000000001R0-2BX0; Thu, 30 Apr 2026 16:22:40 -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, Rik van Riel , Rik van Riel Subject: [RFC PATCH 04/45] mm: mm_init: fix zone assignment for pages in unavailable ranges Date: Thu, 30 Apr 2026 16:20:33 -0400 Message-ID: <20260430202233.111010-5-riel@surriel.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260430202233.111010-1-riel@surriel.com> References: <20260430202233.111010-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-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Rik van Riel 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 f3751fe6e5c3..b3f83452de72 100644 --- a/mm/mm_init.c +++ b/mm/mm_init.c @@ -848,9 +848,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.52.0