From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 884C43D3304 for ; Tue, 28 Apr 2026 13:09:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777381745; cv=none; b=r8uP2t+cBLzD78wEfOFpMV8qPZ002Hc0WDtkxgOp7GCGluPD5D25caVJWqdyJD3z3B1SGlNKC5B6umW32++oXBnvSXvrIy3D074k+Way53K6xXkRpMEYpW+rIk+C1wXlWqnZBzAJJQ1FSldKf57H7h5qd4J6nk/iB9G4yiiFF0E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777381745; c=relaxed/simple; bh=y5Wj2Mshp/u7h62ACdtB57U1YInb0w7gkuhwEVUSYGA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=OZOQWtLb2pryFzZHx1rN5MYsNyDvu8ITT/jbr1blSh9eo3VorwKEddVWCldnSysT0fzFnZ6OxaE6PbP9o9vOyegPgKCFGshaW1j/tt0Nk1LPaAAXqDbtDgnfDhdjW7Sszf5bRWhHFHV62wNieh4fcu6jLFb0bgpG4eDa1WB4vaU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e4JN5naQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="e4JN5naQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74F66C2BCAF; Tue, 28 Apr 2026 13:08:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777381745; bh=y5Wj2Mshp/u7h62ACdtB57U1YInb0w7gkuhwEVUSYGA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=e4JN5naQJ+TlVk6mBeIiP5kBgPhrbIsfSTf/vPhjQnRELi7dpfbVtB7ACoelq3Jap 1zY46otM4NN1WLpNBlVPTdA1TzJh35tO9otOfRJTFL5s+h3VbR7VadwmoPQCR6XGDP NgYZ1g8KA7kTtq1YHu3G1h0OjgQTnJnYjtx3FVNrvmuSvvNrcGXPeZQoBB292gh4Ie hxyYVQSqY8X2a4YFRViC2EZb1IZyWUPFLf44FM8zPleXw3gUUQQ0msO05RFejgRbgY 9F6sK+FnOIcDgn5tr9dN6HAJhet4K1gOT/1BuGP0IGaTdVie8lwjqKQv4pqVuwZ/gB l29nT7E3K7OXQ== Date: Tue, 28 Apr 2026 15:08:55 +0200 From: Mike Rapoport To: Muchun Song Cc: Muchun Song , Andrew Morton , David Hildenbrand , Oscar Salvador , Michael Ellerman , Madhavan Srinivasan , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Nicholas Piggin , Christophe Leroy , aneesh.kumar@linux.ibm.com, joao.m.martins@oracle.com, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 09/49] mm: panic on memory allocation failure in sparse_init_nid() Message-ID: References: <20260405125240.2558577-1-songmuchun@bytedance.com> <20260405125240.2558577-10-songmuchun@bytedance.com> <9FD13495-58E8-4183-AAC0-48E50A694ADE@linux.dev> 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=us-ascii Content-Disposition: inline In-Reply-To: <9FD13495-58E8-4183-AAC0-48E50A694ADE@linux.dev> Hi Muchun, On Tue, Apr 28, 2026 at 08:13:05PM +0800, Muchun Song wrote: > > > On Apr 28, 2026, at 14:56, Mike Rapoport wrote: > > > > On Sun, Apr 05, 2026 at 08:52:00PM +0800, Muchun Song wrote: > >> When vmemmap pages allocation or usemap allocation fails, sparse_init_nid() > >> currently only marks the corresponding section as non-present. However, > >> subsequent code like memmap_init() iterating over PFNs does not check for > >> non-present sections, leading to invalid memory access (additional, > >> subsection_map_init() accessing the unallocated usemap as well). > >> > >> It is complex to audit and fix all boot-time PFN iterators to handle these > >> partially initialized sections correctly. Since vmemmap and usemap allocation > >> failures are extremely rare during early boot, the more appropriate approach > >> is to expose the problem as early as possible. > >> > >> Therefore, use BUG_ON() to panic immediately if allocation fails, instead of > >> attempting a partial recovery that leads to obscure crashes later. > >> > >> Signed-off-by: Muchun Song > > > > Acked-by: Mike Rapoport (Microsoft) > > > >> --- > >> mm/sparse.c | 37 ++++++++----------------------------- > >> 1 file changed, 8 insertions(+), 29 deletions(-) > >> > >> diff --git a/mm/sparse.c b/mm/sparse.c > >> index effdac6b0ab1..5c12b979a618 100644 > >> --- a/mm/sparse.c > >> +++ b/mm/sparse.c > >> @@ -354,19 +354,15 @@ static void __init sparse_init_nid(int nid, unsigned long pnum_begin, > >> unsigned long map_count) > >> { > >> unsigned long pnum; > >> - struct page *map; > >> - struct mem_section *ms; > >> - > >> - if (sparse_usage_init(nid, map_count)) { > >> - pr_err("%s: node[%d] usemap allocation failed", __func__, nid); > >> - goto failed; > >> - } > >> > >> + if (sparse_usage_init(nid, map_count)) > >> + panic("The node[%d] usemap allocation failed\n", nid); > > > > Please consider using memblock_alloc_or_panic() in sparse_usage_init(), it > > would simplify the code even more. > > Hi Mike, > > Should we add a new function like memblock_alloc_node_or_panic? Because > we want to allocate vmemmap pages on the same node. Heh, I missed the nid part :) There are a few _node_ or _nid_ allocation helpers in memblock, starting to add _nopanic for them would be overkill. Let's keep panic()s at call sites. > Thanks. > > -- Sincerely yours, Mike.