kernel/kexec_file.c: load kernel at top of system RAM if required

For kexec_file loading, if kexec_buf.top_down is 'true', the memory which
is used to load kernel/initrd/purgatory is supposed to be allocated from
top to down.  This is also consistent with the old kexec loading
interface.

However, the current arch_kexec_walk_mem() doesn't do like this.  It
ignores checking kexec_buf.top_down, but calls walk_system_ram_res()
directly to go through all resources of System RAM, to try to find a
memory region which can contain the specific kexec buffer, then calls
locate_mem_hole_callback() to allocate memory in that found memory region
from top to down.  This is not right.

Here add checking if kexec_buf.top_down is 'true' in
arch_kexec_walk_mem(), if yes, call the newly added
walk_system_ram_res_rev() to find memory region from top to down to load
kernel.

The problem is the current kexec file loading has different behaviour with
the old kexec loading.  In kexec loading, user space kexec_tools utility
does most of job, it searches in /proc/iomem to try to find a memory
region from top to down to load kernel.  Therefore with the kexec loading,
x86_64 bzImage kernel are all loaded at top of System RAM.  However, the
kexec file loading just searches for available memory region in iomem
resource from bottom to top, then try to allocate from top to down in that
region.  E.g on my testing system with 2G memory as below, the kexec
loading will put kernel near 0x000000013fffffff, while kexec file loading
will put kernel near 0x000000003ffddfff.  There's no bug reported yet,
just we need consider it when take care of the kexec collaboration with
other kernel components like kaslr/hotplug etc, and also the
consistentency between the different kexec interface.

[Mar23 15:13] Linux version 4.16.0-rc3+ (bhe@localhost.localdomain) (gcc version
[  +0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.16.0-rc3+ root=UUID=be8f8e3a-9
[  +0.000000] x86/fpu: x87 FPU will use FXSAVE
[  +0.000000] e820: BIOS-provided physical RAM map:
[  +0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[  +0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[  +0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[  +0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000003ffddfff] usable
[  +0.000000] BIOS-e820: [mem 0x000000003ffde000-0x000000003fffffff] reserved
[  +0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[  +0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[  +0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000013fffffff] usable

I searched on internet and found the original patches posted for adding
bzImage 64 support into the old kexec loading, which is located in user
space kexec_tools utility made by Yinghai, and Vivek and hpa reviewed
patches.  Still I didn't found out why kernel has to be put at top of
system RAM.  I guess low memory are reserved for system usage mostly,
putting kexec kernel at top is safer and no need to exclude those
resereved regions by system or firmware which we may not find out all of
them, but not very sure about it.

Link: http://lkml.kernel.org/r/20180322033722.9279-3-bhe@redhat.com
Signed-off-by: Baoquan He <bhe@redhat.com>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Dave Young <dyoung@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Philipp Rudo <prudo@linux.vnet.ibm.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

1 files changed, 2 insertions, 0 deletions

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index c6a3b6851372..75226c1d08ce 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -518,6 +518,8 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
 					   IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
 					   crashk_res.start, crashk_res.end,
 					   kbuf, func);
+	else if (kbuf->top_down)
+		return walk_system_ram_res_rev(0, ULONG_MAX, kbuf, func);
 	else
 		return walk_system_ram_res(0, ULONG_MAX, kbuf, func);
 }