Re: [PATCH v2 2/2] of: reserved_mem: allocate and map the reserved_mem array early

[Wandun <chenwandun1@gmail.com>]

On 10/9/26 19:27, Marek Szyprowski wrote:
> On 09.10.2026 04:16, Wandun wrote:
>> On 10/8/26 23:24, Marek Szyprowski wrote:
>>> Get rid of the static, limited-size reserved_mem array and replace it
>>> with array allocated by memblock_alloc_raw() and accessed through a
>>> temporary early_memremap() mapping. Such mapping is needed for some
>>> architectures (like ARM64), where linear map is not yet available during
>>> early boot scan. Having a single, writeable array with all reserved
>>> regions removes the need to perform two step initialization introduced
>>> by commit 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved
>>> memory regions are processed"), so all regions can be processed
>>> directly during the early scan again.
>> One concern about the ordering here: the new memblock_alloc_raw() for the
>> reserved_mem array runs *before* the static ("reg") regions are reserved,
>> so the array can be allocated from inside one of them which makes the
>> subsequent static region reservation fail.
> 
> Well, that's what Sashiko already reported. It will be trivial to process
> 'static' regions before doing the reserved_mem allocation, but this in turn
> returns us to the point of not being able to handle their reservation
> failures. I wonder what's worse...

Indeed, every option has its pros and cons.

Could we reconsider the approach from my v2 series [1]:
record the nodes whose early reservation failed in an reserve_failed_nodes
array, and have the late scan skip them.

As I understand it, this handles the vast majority of cases. And if
the number of failed nodes exceeds the reserve_failed_nodes array size,
the system is already misbehaving and the DTS configuration itself
needs to be revisited; even in that case, the v2 approach behaves exactly
the same as the current code, so nothing gets worse.

Also, IIUC, setting a memblock flag may split memblock regions, and since
memblock cannot resize before paging_init(), that would increase the chance
of a panic.

Best regards,
Wandun

[1] https://lore.kernel.org/all/20260818092420.2859026-2-chenwandun1@gmail.com/

> 
> Best regards