From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out162-62-57-64.mail.qq.com (out162-62-57-64.mail.qq.com [162.62.57.64]) (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 3ECA540DFD0 for ; Mon, 15 Jun 2026 16:35:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=162.62.57.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781541338; cv=none; b=M8mQ1RlePud4/C3K105fODcTGA+sbRkpdTIeIYicsp/a9E86R6pNUpLyXYW3IKM2PFfiHD387i1IwrHUb37Apomr21feR+FlGhry1poPzDcLh3E7WEHL7ew/IQCkEvOTD3Vyw/zwo0lGEkIQxnQ9NEUTYJuguc/gOc6XoTOIFw0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781541338; c=relaxed/simple; bh=4S+ITozAf+JELqzPqtTv+nv4+mQkuxjXXjlBv3Xp71w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=DekJAYgNmlrFjLsWLyFy0OlDz5Z08aulYgUAHeW3wLWLbeUZImeSiOFASDWNWLhifqv8fDlkACqWAepsYLIcKdMahMKug/y172tUNi2c3Lv/2Bt/lZRAQMjDYreVExCfvTbsDDKntEA3YzzSlBgaZv06T1gz77Kjadmp7810sk4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com; spf=pass smtp.mailfrom=qq.com; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b=Y1VFmVUo; arc=none smtp.client-ip=162.62.57.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=qq.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qq.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=qq.com header.i=@qq.com header.b="Y1VFmVUo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1781541325; bh=88RkaO2p7eyI794czkPMVu+KIuNd6h2Ce0G8XbguOj4=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=Y1VFmVUowmuB2omrOhI34r0Ab1+o+wE8KP+FXHsruRwS/fpSwS80G9CN6c9vNRszz eRnBPaOoZcTT4NXEl5XDjuWcSwGljcekwIEnYRfx/V5mRmPditfCTE50W/U/SAINaj wODSBUdxIIkQUX2TMpe10m2v8YX1ohEqvQEjg32k= Received: from [192.168.3.157] ([115.156.144.140]) by newxmesmtplogicsvrszb51-1.qq.com (NewEsmtp) with SMTP id 8D523424; Tue, 16 Jun 2026 00:35:21 +0800 X-QQ-mid: xmsmtpt1781541321tv1d6gxea Message-ID: X-QQ-XMAILINFO: MZtEYADUG4AgQcDlRbWn1WDHT9RsUiLODzsMmDkuth3SXU7enl1Cz0cpGkadp4 dtJ9TIoIlmsv+VbrB0mj3JVtfxNNP8fJROFZ1SIHEk12R5/QYWP2tl7HBdab968l3iyj17p9+erT /GzD9oisgYL2Tqqf8DeW/HtQR7gQmRHnrMy5tJdWHYHMff2a3ILp78HU+ZLeBl/K8FC7A7Jl+d3I 77/7zGwryiTG2dhRfR0ubCJcrTDv/i0hpeXq9MYRzK0b2KBlCGFEBGjSq/I3+18rBtAXMUCk7qDg bucfiaR/+OxaahT3pXxGNqcw+NSgAHUBVWkflB6uFi2SYJjCg9IOr/2iB44SdL2YPyhZDxIM8ANG FnaTTwcsAy20JgyczsoNYoFQRfFIFFNtuNqrinDAyKIjCTYmFbaYjOboeJVnsOxtiz5AktuB+Yp2 cFKTkbbNj5k9sh9XaUcbXXPTwsOzI9qYRtcMevSPZJM1x44xt3nUeO5+DQ1phzEcnZeUr1uqPR/E 4KYkc4ctDsOjOGKnPfDF6/9Di5grSeECDqUkrQ4JNBUDTsJxEUk3kKYNuS+AQoFowsM6qn+EjnxV b2dTqPzsudSo0a6sD89jK+3PevK5J7eHU7AhL5LY2Wnfpsa85/o+qAkLT8ISricofWbCNrpajehr i3YvSloL7OapMTPRvTsrcSuKCpfFpZ8m+j+A1Q68nLJTUn4o8D7KgQIjqodMZRqkMV45WSm/Ai/3 vW870bH0Gh5F8irIYk1GWHm9ZqOt65/P/dlNDXvHNT/PinUJIrmVkyfgLkr1IG1DilfIYcPRz2dR ly/qpw+cO642+dBlFjdg2ER3yx3w+RoXyf3nAwnaBHHNenCzteFrOjE32Ko5UAA5Ae6Vurbl47ko r/uebomp6YPlybogMdkMQJvGHshsqpMQ/fI7zgFsFp762mOleH+y1Avtv52GSh9QIt9PWeSAvLUj G5jAN/1a+268rq7nyyVZGLuFm6FRzKFexHaZwouPmef48lo7DGUTe/gL5Kfzz5zTVdbtCGFJWyGO kM3A0YyaD50PwQyxKXWByXOqdY2GeY+6e+54IZOQ== X-QQ-XMRINFO: MPJ6Tf5t3I/ylTmHUqvI8+Wpn+Gzalws3A== X-OQ-MSGID: <3ef0ecaa-3e0b-4583-8404-d552c62489db@qq.com> Date: Tue, 16 Jun 2026 00:35:21 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 07/19] mm/sparse: Move subsection_map_init() into sparse_init() To: Muchun Song , Oscar Salvador , David Hildenbrand , Andrew Morton , Madhavan Srinivasan , Michael Ellerman Cc: Muchun Song , 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 References: <20260612035903.2468601-1-songmuchun@bytedance.com> <20260612035903.2468601-8-songmuchun@bytedance.com> From: XIAO WU In-Reply-To: <20260612035903.2468601-8-songmuchun@bytedance.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Muchun, 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. This patch introduces a new `sparse_init_subsection_map()` that iterates over all memblock ranges and calls `sparse_init_subsection_map_range()`: > +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); 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. `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()`:     ms = __nr_to_section(nr);     subsection_mask_set(ms->usage->subsection_map, pfn, pfns); `ms->usage` is NULL because `sparse_init_early_section()` was never called for this section, causing a NULL pointer dereference. I was able to reproduce this on x86_64 with 4-level paging by booting with `memmap=4G@0x400080000000` to place a memblock range beyond the ~64 TiB `max_sparsemem_pfn` limit.  The kernel crashes during early boot:   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 The fix is a one-line NULL check in sparse_init_subsection_map_range(): --- a/mm/sparse-vmemmap.c +++ b/mm/sparse-vmemmap.c @@ -608,6 +608,8 @@ void __init sparse_init_subsection_map(unsigned long pfn,          pfns = min(nr_pages, PAGES_PER_SECTION                  - (pfn & ~PAGE_SECTION_MASK));          ms = __nr_to_section(nr); +        if (!ms->usage) +            continue;          subsection_mask_set(ms->usage->subsection_map, pfn, pfns); 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. Thanks, Xiao