s390 and crashk_res

s390 and crashk_res

[Mike Rapoport]

Hello,

I'm trying to consolidate setup of iomem_resource as it is very similar
across several architectures.  

Among the differences I've encountered is that s390 keeps crashk_resource
is not a child of "System RAM" and commit 4e042af463f8 ("s390/kexec: fix
crash on resize of reserved memory") added a comment that explicitly says
that "... crash kernel resource should not be part of the System RAM
resource".

I could not find what is the reason for this neither in the kernel nor in
kexec sources.

Any help will be greatly appreciated!

-- 
Sincerely yours,
Mike.

Re: s390 and crashk_res

[Gerald Schaefer]

On Mon, 10 May 2021 17:00:58 +0300
Mike Rapoport <rppt@linux.ibm.com> wrote:

> Hello,
> 
> I'm trying to consolidate setup of iomem_resource as it is very similar
> across several architectures.  
> 
> Among the differences I've encountered is that s390 keeps crashk_resource
> is not a child of "System RAM" and commit 4e042af463f8 ("s390/kexec: fix
> crash on resize of reserved memory") added a comment that explicitly says
> that "... crash kernel resource should not be part of the System RAM
> resource".
> 
> I could not find what is the reason for this neither in the kernel nor in
> kexec sources.
> 
> Any help will be greatly appreciated!
> 

Hello Mike,

Heiko is out of the office for a couple of weeks, but I think chances
are good that this is just some historic or cosmetic artifact.

We apparently wanted to make extra sure that the crashkernel memory
is as invisible to the kernel as possible, e.g. by not even having
in it in the kernel 1:1 mapping and also w/o struct pages. This was
changed by Heikos patch, as it did not work well with the crashkernel
resizing. The patch did not change the "System RAM" hierarchy, IIUC,
it just added the comment. I assume that both the 1:1 mapping and also
the "System RAM" exclusion were just some overly cautious measures,
just because it was possible.

Since commit 1a085d0727af ("kexec: Set IORESOURCE_SYSTEM_RAM for System
RAM") and bd7e6cb30ced ("resource: Change walk_system_ram() to use System
RAM type"), it should actually not really matter which hierarchy we use
for /proc/iomem, because crashk_res will be flagged as System RAM anyway,
and thus also be visible for any System RAM resource walkers, IIUC.

Those commits went upstream just a bit before Heikos commit, and it might
just not have been noticed (until now) that we do not really hide the
crashk_res from System RAM anymore. I also see no technical impact, other
than cosmetic reasons, i.e. it will not show up as child in /proc/iomem,
but for all other purposes it would still be treated as System RAM, at
least after the two commits mentioned above.

So I would assume that the comment is just misleading, but I cannot
really say for sure. Maybe Heiko can add some more insight when he
returns.

Regards,
Gerald