Re: [PATCH 2/2] arm/mm : Report actual image regions in /proc/iomem
From: Ard Biesheuvel
Date: Mon Mar 06 2023 - 08:01:51 EST
On Mon, 6 Mar 2023 at 13:28, Russell King (Oracle)
<linux@xxxxxxxxxxxxxxx> wrote:
>
> On Mon, Mar 06, 2023 at 09:14:23PM +0900, Jungseung Lee wrote:
> > Hi, Russell
> >
> > > -----Original Message-----
> > > From: Russell King (Oracle) <linux@xxxxxxxxxxxxxxx>
> > > Sent: Monday, March 6, 2023 8:10 PM
> > > To: Jungseung Lee <js07.lee@xxxxxxxxxxx>
> > > Cc: linus.walleij@xxxxxxxxxx; amit.kachhap@xxxxxxx; ardb@xxxxxxxxxx;
> > > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> > > keescook@xxxxxxxxxxxx; js07.lee@xxxxxxxxx
> > > Subject: Re: [PATCH 2/2] arm/mm : Report actual image regions in
> > > /proc/iomem
> > >
> > > On Mon, Mar 06, 2023 at 02:51:55PM +0900, Jungseung Lee wrote:
> > > > The resource reservations in /proc/iomem made for the kernel image
> > > > did not reflect the gaps between text, rodata, and data.
> > > > Add the "rodata" resource and update the start/end calculations.
> > > >
> > > > Before :
> > > > 04000000-2f7fffff : System RAM
> > > > 04100000-04cfffff : Kernel code
> > > > 04e00000-05369a27 : Kernel data
> > > >
> > > > After :
> > > > 04000000-2f7fffff : System RAM
> > > > 04100000-049fffff : Kernel code
> > > > 04a00000-04cb2fff : Kernel rodata
> > > > 04e00000-05369a27 : Kernel data
> > >
> > > NAK. This is API, and programs do read and parse this file. It is
> > > important that this file reports these parameters in a similar way to
> > > other architectures. Other architectures do not split up the
> > > individual regions.
> > >
> >
> > Sounds like an important point, but I failed to find which programs use it
> > as an API. Could you tell me which program uses it as an API?
> >
> > In fact, x86 architecture also split up the individual regions in this way.
> > In addition, most architectures separate the "Kernel bss" area, but arm does
> > not.
>
> Take a look at kexec-tools - that certainly does parse /proc/iomem
> looking for entries such as "Kernel code" and "Kernel data".
>
> It's fine for an architecture to decide to do something else if it
> started to do it early on, but not when something has been established
> for decades.
>
Agree with Russell here.
It would be helpful if you could explain why you think this needs to be changed.