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

[Marek Szyprowski]

On 10.10.2026 08:40, Wandun wrote:
> 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.
Frankly speaking I would only keep the information if any of the early reservation
failed or not and just print information that "Early reservation of some memory
regions failed - system might be unstable, please fix Your device-tree". I see no
point over-engineering this more for no visible benefit.

I will send v3 of this patchset with such assumption.
> 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.
The memblock flags are already set for each reserved region, so adding one more
flags probably won't increase significantly the number of memblock entries.
Adjacent regions with same flags are already being merged by the memblock layer,
so many adjacent reserved regions might be covered by a single memblock entry.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland