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 6D92D3769F6 for ; Tue, 16 Jun 2026 03:05:25 +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=1781579127; cv=none; b=PYgzKhh/OjazrJr9DlKGqwHIe8P9kFZ5/MH0x32zBVT5F2j5zmyyfzwz/iSYbE4/sBzgAmvyL/qdjiY5BJZlEuYhFdkLWlxxgRF4Aq/ZcVO0Kn+YvvLg/8gBZ3OdNAqEWbKb0KJvR8JeJCiz2g+pgBS79U1N4HkmW3BcODjX0EM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781579127; c=relaxed/simple; bh=a2VJ1/8fDSP2R9n3UIHE+0WC9CX1qVO0ucWI/Jx0eXs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=HUks/vWfN+hSK4cE3vZzpHIdvCNQ3XPVCQfaamgTA614+i7C+WPQ30Wg7AvH4yC66xOGdPh15TJYOTOMcRmRSpEW4odoZpZfPL8byJsxjcKpq6SJxHU48TE8WePtaM02l/3Sf+sgl3xDUeokmH91k2DD1xuRmKXJ42WPGBNhAls= 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=jjiaLzgs; 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="jjiaLzgs" Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781579123; 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=UCuy06I4nPKaRj4EdDj906BN7ekSIsZfFchCV1iyaYU=; b=jjiaLzgsV6Wzixa47UJBYqkzHBZu+5T+BdwBeaP3Le78Qf58EYhpy7SAeR8EzB+hv4DRBm C+3deN0BgPOxgtnYgt9wTPs2kPyjRObnf7P2aN6RXqLyTmgaIQgS+Vx5m0zg5fsawIjQqp B1YPvSV49572/4yXnAe+FSAUoj5Ddfg= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Subject: Re: [PATCH v4 07/19] mm/sparse: Move subsection_map_init() into sparse_init() X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: Date: Tue, 16 Jun 2026 11:04:38 +0800 Cc: Muchun Song , Oscar Salvador , David Hildenbrand , Andrew Morton , Madhavan Srinivasan , Michael Ellerman , Mike Rapoport , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Nicholas Piggin , Christophe Leroy , Ritesh Harjani , "Aneesh Kumar K . V" , linuxppc-dev@lists.ozlabs.org, Mike Kravetz Content-Transfer-Encoding: quoted-printable Message-Id: References: <20260612035903.2468601-1-songmuchun@bytedance.com> <20260612035903.2468601-8-songmuchun@bytedance.com> To: XIAO WU X-Migadu-Flow: FLOW_OUT > On Jun 16, 2026, at 00:35, XIAO WU wrote: >=20 > Hi Muchun, Hi, >=20 > Muchun Song wrote: > > mm/sparse: Move subsection_map_init() into sparse_init() > > > > This commit moves subsection_map_init() from free_area_init() into > > sparse_init() so that sparse-specific setup stays together instead = of being > > split across the generic free_area_init() path. >=20 > This patch introduces a new `sparse_init_subsection_map()` that = iterates > over all memblock ranges and calls = `sparse_init_subsection_map_range()`: >=20 > > +void __init sparse_init_subsection_map(void) > > +{ > > + int i, nid; > > + unsigned long start, end; > > + > > + for_each_mem_pfn_range(i, MAX_NUMNODES, &start, &end, &nid) > > + sparse_init_subsection_map_range(start, end - start); >=20 > However, earlier in `sparse_init()`, `memblocks_present()` calls > `memory_present()`, which internally caps PFN ranges at > `max_sparsemem_pfn` via `mminit_validate_memmodel_limits()`. Sections > beyond this cap never have `ms->usage` allocated. >=20 > `for_each_mem_pfn_range()` returns the raw, uncapped memblock ranges. > If a range extends beyond `max_sparsemem_pfn`, then inside > `sparse_init_subsection_map_range()`: >=20 > ms =3D __nr_to_section(nr); > subsection_mask_set(ms->usage->subsection_map, pfn, pfns); >=20 > `ms->usage` is NULL because `sparse_init_early_section()` was never > called for this section, causing a NULL pointer dereference. Thanks for your report. IIUC, it is a pre-existing issue. >=20 > I was able to reproduce this on x86_64 with 4-level paging by booting > with `memmap=3D4G@0x400080000000` to place a memblock range beyond the > ~64 TiB `max_sparsemem_pfn` limit. The kernel crashes during early = boot: >=20 > node -1: [mem 0x0000400080000000-0x000040017fffffff] > ------------[ cut here ]------------ > WARNING: mm/sparse.c:142 at sparse_init+0x1ac/0x8a0 > ... > PANIC: early exception 0x0d IP = 10:...sparse_init_subsection_map+0x12f/0x250 > RIP: 0010:sparse_init_subsection_map+0x12f/0x250 > Call Trace: > sparse_init+0x69f/0x8a0 > mm_core_init_early+0x12fa/0x20c0 > start_kernel+0x89/0x4e0 >=20 > The fix is a one-line NULL check in = sparse_init_subsection_map_range(): Would you mind sending a separate fix patch since it is not introduced = by this patch? I would like to review it. Muchun, Thanks. >=20 > --- a/mm/sparse-vmemmap.c > +++ b/mm/sparse-vmemmap.c > @@ -608,6 +608,8 @@ void __init sparse_init_subsection_map(unsigned = long pfn, > pfns =3D min(nr_pages, PAGES_PER_SECTION > - (pfn & ~PAGE_SECTION_MASK)); > ms =3D __nr_to_section(nr); > + if (!ms->usage) > + continue; > subsection_mask_set(ms->usage->subsection_map, pfn, pfns); >=20 > On most systems `max_sparsemem_pfn` is large enough that this is never > hit, but on 32-bit or PAE configurations where the limit is much = lower, > the mismatch between `for_each_mem_pfn_range()` and > `mminit_validate_memmodel_limits()` can trigger with reasonable memory > sizes. >=20 > Thanks, > Xiao >=20 >=20