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

[Marek Szyprowski]

On 04.11.2026 09:19, Geert Uytterhoeven wrote:
> On Tue, 3 Nov 2026 at 20:25, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote:
>> On 03.11.2026 19:04, Geert Uytterhoeven wrote:
>>> On Thu, 15 Oct 2026 at 10:29, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote:
>>>> Get rid of the static, limited-size reserved_mem array and replace it
>>>> with array allocated by memblock_alloc_raw() and accessed directly or
>>>> through a temporary early_memremap() mapping (depending on the
>>>> architecture support). Such mapping is needed for some architectures
>>>> (like ARM64), where linear map is not yet available during early boot
>>>> scan. The array is allocated from the bottom of RAM to avoid placing it
>>>> in highmem area, because some architectures (e.g. Xtensa, C-SKY, MIPS32)
>>>> set the memblock limit to the end of lowmem only after the early scan.
>>>> The early mapping is not used on PPC64, where the scan is done before
>>>> early_ioremap_setup(), but the memory allocated by memblock is already
>>>> accessible at that point.
>>>>
>>>> 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 during the
>>>> early scan again.
>>>>
>>>> The reserved_mem array is allocated only after all static (defined by
>>>> the 'reg' property) regions are marked as reserved or no-map, so it
>>>> cannot be placed in any of them. Errors of the early reservations are
>>>> not recorded per region, only the fact that some of them failed is
>>>> stored and a message asking to fix the device-tree is printed. The
>>>> region specific init functions for the static regions are then called
>>>> in a separate pass, once the array is available. Then all dynamically
>>>> allocated reserved regions are processed.
>>>>
>>>> Suggested-by: Mike Rapoport <rppt@xxxxxxxxxx>
>>>> Link: https://lore.kernel.org/all/asc6brs_g0ky0wOM@xxxxxxxxxx/
>>>> Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
>>> Thanks for your patch, which is now commit aa05faf815836c47 ("of:
>>> reserved_mem: allocate and map the reserved_mem array early")
>>> in dt-rh/for-next.
>>>
>>> This causes an early crash on BeagleV Starlight Beta:
>>>
>>>  [...]
>>>  earlycon: uart0 MMIO32:0x0000000012440000 (options '115200n8')
>>>  printk: legacy bootconsole [uart0] enabled
>>>  printk: debug: skip boot console de-registration.
>>>  efi: UEFI not found.
>>> -OF: reserved mem: 0x00000000fb000000..0x00000000fcffffff (32768 KiB)
>>> map non-reusable framebuffer@fb000000
>>> -OF: reserved mem: 0x00000000f9000000..0x00000000f9ffffff (16384 KiB)
>>> map non-reusable framebuffer@f9000000
>>> -OF: reserved mem: 0x00000000d0000000..0x00000000f7ffffff (655360 KiB)
>>> map non-reusable framebuffer@d0000000
>>> -OF: reserved mem: 0x00000000c9000000..0x00000000ccffffff (65536 KiB)
>>> map non-reusable framebuffer@c9000000
>>> -OF: reserved mem: 0x00000000fa000000..0x00000000faffffff (16384 KiB)
>>> nomap non-reusable dma-reserved@fa000000
>>> -Reserved memory: created DMA memory pool at 0x000000107a000000, size 16384 KiB
>>> -OF: reserved mem: initialized node linux,dma@107a000000, compatible
>>> id shared-dma-pool
>>> -OF: reserved mem: 0x000000107a000000..0x000000107affffff (16384 KiB)
>>> nomap non-reusable linux,dma@107a000000
>>> -SBI HSM extension detected
>>> -[...]
>>> +Oops - store (or AMO) access fault [#1]
>>> +Modules linked in:
>>> +CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted
>>> 7.4.0-rc1-starlight-00002-gaa05faf81583 #411 PREEMPT
>>> +Hardware name: BeagleV Starlight Beta (DT)
>>> +epc : __memset+0x68/0xfe
>>> + ra : fdt_scan_reserved_mem+0x3a4/0x80a
>>> +epc : ffffffff8087fd88 ra : ffffffff80a313c8 sp : ffffffff81403c20
>>> + gp : ffffffff814dc6c0 tp : ffffffff8140cf80 t0 : ffffffc4fea38ff0
>>> + t1 : 0000000080200000 t2 : ffffffc4fec03008 s0 : ffffffff81403d10
>>> + s1 : ffffffffffffffff a0 : ffffffc4fea39000 a1 : 0000000000000000
>>> + a2 : 00000000000000f0 a3 : ffffffc4fea390f0 a4 : 0000000000000008
>>> + a5 : ffffffff8087fd88 a6 : 00000000000000f0 a7 : 0000000000001000
>>> + s2 : ffffffc4fec00000 s3 : 00000000000000f0 s4 : 0000000000000000
>>> + s5 : 0000000000002de0 s6 : 0000000000000006 s7 : fffffffffefefefe
>>> + s8 : ffffffc4fec02fd4 s9 : ffffffff8148e318 s10: fffffffffefefeff
>>> + s11: ffffffc4fea39000 t3 : ffffffff8150df00 t4 : ffffffff8150df00
>>> + t5 : ffffffff8150df00 t6 : ffffffff8150df78 ssp : 0000000000000000
>>> +status: 0000000200000100 badaddr: ffffffc4fea39000 cause: 0000000000000007
>>> +[<ffffffff8087fd88>] __memset+0x68/0xfe
>>> +[<ffffffff80a2f63a>] early_init_fdt_scan_reserved_mem+0xa4/0x110
>>> +[<ffffffff80a06c8e>] paging_init+0x17c/0x46a
>>> +[<ffffffff80a046dc>] setup_arch+0xdc/0x584
>>> +[<ffffffff80a009b8>] start_kernel+0x98/0x940
>>> +Code: 0000 8793 00e7 8305 97ba 8782 b023 00b2 b423 00b2 (b823) 00b2
>>> +---[ end trace 0000000000000000 ]---
>>> +Kernel panic - not syncing: Fatal exception in interrupt
>>> +---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
>>>
>>> Reverting the commit fixes the issue.
>> Does moving early_init_fdt_scan_reserved_mem() to the end of setup_bootmem()
>> in arch/riscv/mm/init.c change anything?
> Unfortunately that doesn't make a difference.

Well, that's still a potential issue, so I will send a separate fix for that.


>> Could You provide a full boot log from the working kernel and /proc/iomem dump?
> Sent by personal email.
> The relevant part of /proc/iomem is:
>
>     80000000-cfffffff : System RAM
>       80200000-80201fff : Reserved
>       80202000-81730bf7 : Kernel image
>         80202000-80aa7e73 : Kernel code
>         81000000-813fffff : Kernel rodata
>         81600000-816dd9ff : Kernel data
>         816de000-81730bf7 : Kernel bss
>       81730bf8-817fffff : Reserved
>       88000000-88007fff : Reserved
>       9c000000-c7ffffff : Reserved
>       c9000000-ccffffff : Reserved
>     d0000000-f7ffffff : Reserved
>     f8000000-f8ffffff : System RAM
>     f9000000-fcffffff : Reserved
>     fd000000-27fffffff : System RAM
>       2772e1000-2773a0fff : Reserved
>       2773a1000-277fa1fff : Reserved
>       277fa2000-277fcbfff : Reserved
>       277fce000-277fcefff : Reserved
>       277fcf000-27ffcffff : Reserved
>       27ffd0000-27fff6fff : Reserved
>       27fff7000-27fffffff : Reserved


This turned out to be a bootloader issue on this board. The protected opensbi
memory region was placed before kernel and not properly described in dt.
Kernel treated it as a normal memory resulting in the above crash. Confirmed
by Geert in private discussion.


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