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

Muchun Song
2026-04-29T03:15:22Z

> On Apr 28, 2026, at 21:08, Mike Rapoport <rppt@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@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@bytedance.com>
>>>
>>> Acked-by: Mike Rapoport (Microsoft) <rppt@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.