[PATCH 09/49] mm: panic on memory allocation failure in sparse_init_nid()

[Muchun Song]

> On Apr 28, 2026, at 21:08, Mike Rapoport <rppt at kernel.org> wrote:
> 
> Hi Muchun,
> 
> On Tue, Apr 28, 2026 at 08:13:05PM +0800, Muchun Song wrote:
>> 
>>> On Apr 28, 2026, at 14:56, Mike Rapoport <rppt at kernel.org> 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 <songmuchun at bytedance.com>
>>> 
>>> Acked-by: Mike Rapoport (Microsoft) <rppt at kernel.org>
>>> 
>>>> ---
>>>> 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.

We can add a panic inside memmap_alloc() because it is used specifically for
memmap allocation. To some extent, this also reduces the number of places where
callers need to add a panic. What do you think?

Thanks.

> 
>> Thanks.
>> 
>> 
> 
> -- 
> Sincerely yours,
> Mike.