Re: [PATCH 0/2] Some small improvements to reserve_mem

[Mike Rapoport]

Hi Guilherme,

On Tue, Feb 17, 2026 at 04:45:05PM -0300, Guilherme G. Piccoli wrote:
> Currently the "reserve_mem" parsing is lacking information both
> if it works or not. It can fail in many ways, so I'm adding some
> messages to help users determine failure.

Yep, these are useful. 

> At the same time, if it succeeds, the only place I can "see" it
> is in the accounting of reserved memory, as the following kernel message:
> 
> [0.086881] Memory: 3958852K/4189472K available (19671K kernel code, 2893K rwdata, 9724K rodata, 4340K init, 5040K bss, 220244K reserved, 0K cma-reserved)
> 
> Since "crashkernel=" reservations are shown in both kernel log and /proc/iomem
> and other unused memory buffers appear in /proc/iomem as "RAM buffer" entries,
> I've added hereby a debugfs entry for "reserve_mem". Though I didn't love the
> implementation, I think it's not so hideous so decided to send, please lemme
> know what you think and if we should improve code or even discard the idea heheh

crashkernel reservations are part of the ABI and kexec tools parse them in
userspace, so they should be exposed. reserve_mem consumers are in the
kernel, so if the reservation succeeds there's no real need for userspace
to see where are the reserve_mem regions.

I don't generally object showing them in debugfs, but the changelog for
debugfs addition should give more details why they would be useful rather
than just say that unlike crashkernel they don't show up anywhere.
 
> Notice that, with this change, the memblock debugfs folder ends-up showing
> always, no matter if we have ARCH_KEEP_MEMBLOCK set or if reserve_mem is set.
> Thanks in advance for reviews/comments!
> 
> 
> Guilherme G. Piccoli (2):
>   mm/memblock: Print out errors on reserve_mem parser
>   mm/memblock: Add reserve_mem debugfs info
> 
>  mm/memblock.c | 65 ++++++++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 54 insertions(+), 11 deletions(-)
> 
> -- 
> 2.50.1
> 
> 

-- 
Sincerely yours,
Mike.