From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=91.218.175.29 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793338351; b=uDRyA0Tq+otIzh0wSCdFv55k+oCTHH3aUGvo6EzJh6mtCPjsb5QgZuigcf3oHoE/q5/3 RuMfwdLXhHgD3Vd7M1o0i0roIqKfmCAjYilqevCJMuEKfsU+4Um8tIjsIst11gZJk3/5N ukt4g9AV08UTaXXt/CBHjHLG5x9yvsWVWwW+Jp7xGtsyOXLW/U9L31bAY98/vt6t+qGS7 UbcEvzW4G3+m6mkZKhm5tlvj2/sRstucIrXHIlHlQc/Bu2IfI5oNfMGkoVo+9sglwPR7s LfYcCVt3ObHIU/3JLC/oyCUuoXvxToJ21skDgJHmvcxVB3afdx/6r+EntRSRgH5JJOA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793338351; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References: To:X-Mailer; bh=VTDrdrBuAyTJnkqjgvXYYtVwc9zTl+F88XwMGcc4YDE=; b=TpLu4Wyb3NdSdew6ZAhx4q5AM3z6Vl0Qw+DQ4IYHLPk4QZHO4wedDx4zgcZq34qyUQDc 06dlw/+9YSeyKkw1mBajnio5SgqxwVDLR/dwW387UCBwGadWoUNUNaEr0IgoId3/oSQLi SDUwBuRsXEtXrjiGNOzzJVUcth1eblhVxbP9eiWqXvx4bZo4I63I/h/Ly/A9VaPndlnki 1VEWv20Lcr9AMdTJ0/pHfvuq6mo0IOQVd/ZwrQEzzGbot3Wkj7sNvioz8MHBy2xESY6wI oJS51+aLERWKHHU3jFWm6WbpQwZl6EAbszDKrCzBnZL9GpBZjGzJeskAz3aZWPyPcag== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=vHfRjYMT; arc=none smtp.remote-ip=91.218.175.29 Received: from mta0.migadu.com (out-29.mta0.migadu.com [91.218.175.29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5E0E606A334 for ; Fri, 30 Oct 2026 05:32:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org C5E0E606A334 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, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=vHfRjYMT X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=Bf0WWkeJSETIqyNNL0Tk2W1KhY+0SCl/fI1XWH+Qygc=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1793338342; v=1; x=1793943142; b=vHfRjYMTLE8GNmV/NQ930J2ywQJhyanjVI75XVY+Rep9T7tsczB1jt3b7nefwWbYQQHhTYpb iqzg8eNAu1Xwp0lliVRb1Bc0n0dDbxlw7ENRHSVJ1UOiue1mIXVgC4W1E5mOo6hJME16DhnrQBq go8H6oQ4AOnRkh5x1foQvjtU= X-Envelope-To: linux-kernel@vger.kernel.org Received: by mta12.migadu.com with ESMTPS id 9f9ebc0d777873bb; Fri, 30 Oct 2026 05:32:22 +0000 X-Mizu-Trace-ID: 9f9ebc0d777873bb X-Migadu-Flow: FLOW_OUT Content-Type: text/plain; charset=us-ascii X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3901.100.1.1.12\)) Subject: Re: [PATCH] mm/hugetlb_vmemmap: Fix usemap overrun on nodes with multiple ranges From: Muchun Song In-Reply-To: <20261029212137.3141875-1-tim.c.chen@linux.intel.com> Date: Fri, 30 Oct 2026 13:32:06 +0800 Cc: Andrew Morton , Oscar Salvador , David Hildenbrand , Frank van der Linden , Mike Rapoport , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Mohini Narkhede , Pooja Jain , Doug Nelson Content-Transfer-Encoding: 7bit Message-Id: <0611C182-4A76-4751-A04B-0849EC31DAD3@linux.dev> References: <20261029212137.3141875-1-tim.c.chen@linux.intel.com> To: Tim Chen X-Mailer: Apple Mail (2.3901.100.1.1.12) > On Oct 30, 2026, at 05:21, Tim Chen wrote: > > sparse_init_nid() allocates one usemap slot (struct mem_section_usage) > per present section in [pnum_begin, pnum_end), and > sparse_init_early_section() hands them out in order, with a BUG_ON() when > they run out. hugetlb_vmemmap_init_early(nid) however initializes the > sections of every bootmem gigantic page on the node, including pages > outside the range being initialized. If a node's memory is split into > more than one range, sparse_init() calls sparse_init_nid() once per range, > and this takes more slots than were allocated. The same happens if a > gigantic page straddles a node boundary. > > For example, with this SRAT layout every node has a small range below 4G > and a large range above 4G: > > Node 0 PXM 0 [mem 0x00000000-0x2fffffff] 768 MB (low) > Node 0 PXM 0 [mem 0x100000000-0x80cfffffff] (high) > Node 1 PXM 1 [mem 0x30000000-0x5fffffff] 768 MB (low) > ... > > In 128 MB memory sections (x86_64 SECTION_SIZE_BITS = 27), node 0's low > range is sections 0x00-0x05 (6 present sections) and its high range is > sections 0x20-0x1019. The low ranges of the other nodes are 4 or 6 > sections, all smaller than the 8 sections of a 1G page. > > Node 0's first range has 6 sections, so 6 slots. With "hugepagesz=1G > hugepages=400", hugetlb_vmemmap_init_early(0) then initializes node 0's > 1G page at 0x67c0000000 (sections 0xcf8-0xcff, in its high range), and > the 7th section hits the BUG_ON() (seen on v7.2.6): > > kernel BUG at mm/sparse.c:268! > RIP: 0010:sparse_init_early_section+0x9f/0xb0 > RAX: 0000000000200000 RBX: 0000000000000cfe RCX: 0000000000000020 > RDX: 0000000000000cfe RSI: ffd7e1d09fc00000 RDI: ff252cb28ffb3f50 > R10: ff252cb28ffb3d40 R13: 0000000000000d00 > Call Trace: > hugetlb_vmemmap_init_early+0xe1/0x140 > sparse_init_nid+0x56/0x370 > sparse_init+0x192/0x2b0 > free_area_init+0x7f/0x690 > start_kernel+0x64/0x540 > > Here RDX is the section number, and R10/RDI are 6 slots apart: the start > of the usemap buffer and its current position, which is the end. A detailed analysis. > > Pass the section range to hugetlb_vmemmap_init_early() and only pre-HVO a > page whose sections are all present and within it. Ranges are disjoint, > so each page is handled once, in its own range. > > Skipped pages are not marked HUGE_BOOTMEM_HVO. Their sections get a > regular memmap from sparse_init_nid(), and the pages are optimized later > by hugetlb_vmemmap_optimize_bootmem_folios(). Thanks for fixing this. However, the master branch has already switched to section-based vmemmap optimization, it has been already fixed. So this fix should target the stable kernels (6.18, 7.2 and 7.3). The change LGTM. So: Reviewed-by: Muchun Song Thanks.