| Age | Commit message (Collapse) | Author |
|---|
|
AFAICT, there's no downside to this, and running into this each time
I want to kexec (and, presumably, a significant chunk of the population,
since lockdown is quite popular) on some machines,
then going to the manual, then finding out I want the /auto/ flag(!)
is quite annoying:
# kexec -l /boot/vmlinuz-6.1.0-3-amd64 --initrd /boot/initrd.img-6.1.0-3-amd64 --reuse-cmdline
kexec_load failed: Operation not permitted
entry = 0x46eff7760 flags = 0x3e0000
nr_segments = 7
segment[0].buf = 0x557cd303efa0
segment[0].bufsz = 0x70
segment[0].mem = 0x100000
segment[0].memsz = 0x1000
segment[1].buf = 0x557cd3046fe0
segment[1].bufsz = 0x190
segment[1].mem = 0x101000
segment[1].memsz = 0x1000
segment[2].buf = 0x557cd303f6e0
segment[2].bufsz = 0x30
segment[2].mem = 0x102000
segment[2].memsz = 0x1000
segment[3].buf = 0x7f658fa37010
segment[3].bufsz = 0x12a51b5
segment[3].mem = 0x46a55a000
segment[3].memsz = 0x12a6000
segment[4].buf = 0x7f6590ce1210
segment[4].bufsz = 0x7e99e0
segment[4].mem = 0x46b800000
segment[4].memsz = 0x377c000
segment[5].buf = 0x557cd3039350
segment[5].bufsz = 0x42fa
segment[5].mem = 0x46eff2000
segment[5].memsz = 0x5000
segment[6].buf = 0x557cd3032000
segment[6].bufsz = 0x70e0
segment[6].mem = 0x46eff7000
segment[6].memsz = 0x9000
Closes: https://bugs.debian.org/1030248
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@kernel.org>
|
|
In LoongArch, when using the --reuse-cmdline option to reuse the current
command line, it may lead to redundancy (like kexec, initrd command line
arguments). In order to avoid the possible impact of initrd removal on other
architectures, remove_parameter will be called in a specific architecture
for processing.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@kernel.org>
|
|
Currently, my_exec() does not expect the Xen KEXEC_CMD_kexec hypercall
to return on success, because it assumes that the hypercall always
triggers an immediate reboot. However, for Live Update, the hypercall
merely schedules the kexec operation and returns; the actual reboot
happens asynchronously. [1]
Therefore, rework the Xen code path of my_exec() such that it does not
treat a successfully processed Live Update request as an error. Also,
rephrase the comment above the function to remove ambiguity.
[1] https://lists.xen.org/archives/html/xen-devel/2021-05/msg00286.html
Signed-off-by: Raphael Ning <raphning@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Commit 4f77da634035 ("kexec-tools: Fix kexec_file_load(2) error
handling") introduced EFALLBACK for scenarios where fallbacking back
to kexec_load syscall is likely to work and dropped printing error
message for these scenarios. But printing error message for other
failure scenarios was inadvertently dropped. Restore printing error
message for such cases.
Fixes: 4f77da634035 ("kexec-tools: Fix kexec_file_load(2) error handling")
Cc: Petr Tesarik <ptesarik@suse.com>
Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Reviewed-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This way the size of the command line that get_command_line() can handle
is no longer fixed.
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
slurp_file() cannot be used to read proc files, as they are returning
a size of zero in stat(). Add a function slurp_proc_file() which is
similar to slurp_file(), but doesn't require the size of the file to
be known.
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
According to kexec(8) manpage, --status (-S) works with both
normal kexec (loaded by -l) and crash kernel (loaded by -p) image
types, and defaults to the latter. However, the implementation does
not match the description: `kexec -l -S` queries the -p image type
as if -l were not specified. This is because there is no internal
flag defined for the normal kexec type, and -S treats the zero flag
as the trigger for the default behaviour (-p).
Fix that by making sure the default behaviour for -S is not applied
when the -l option is present.
Signed-off-by: Raphael Ning <raphning@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
On both Linux and Xen, an exit code of 0 from `kexec --status`
indicates that the kexec image being queried is NOT loaded, which
is contrary to what the man page and usage() say.
Signed-off-by: Raphael Ning <raphning@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When compiling for 32-bit:
kexec/kexec.c: In function ‘cmdline_add_liveupdate’:
kexec/kexec.c:1192:30: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
1192 | sprintf(buf, " liveupdate=%luM@0x%lx", lu_sizeM, lu_start);
| ~~^ ~~~~~~~~
| | |
| | uint64_t {aka long long unsigned int}
| long unsigned int
| %llu
kexec/kexec.c:1192:37: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
1192 | sprintf(buf, " liveupdate=%luM@0x%lx", lu_sizeM, lu_start);
| ~~^ ~~~~~~~~
| | |
| | uint64_t {aka long long unsigned int}
| long unsigned int
| %llx
Indeed, "uint64_t" is "unsigned long long" on 32-bit formats, and
"unsigned long" on 64-bit formats.
Fix this by casting to "unsigned long long", and formatting using "%llu"
or "%llx".
Fixes: b13984c6f9ec7fdd ("kexec: Introduce --load-live-update for xen")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Where Y specifies how much memory to reserve for the dump-capture kernel
and X specifies the beginning of this reserved memory. So Y should be
placed before X.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add missing close() call.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Reviewed-by: Khalid Aziz <khalid@gonehiking.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fixes: 28d4ab532808 ("Add generic debug option")
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This signals xen to do a KEXEC_TYPE_LIVE_UPDATE kexec operation.
Signed-off-by: Varad Gautam <vrd@amazon.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Support loading a live update image for xen from kexec userspace.
For a multiboot2 Elf on a xen setup, this will:
- load the Elf into KEXEC_RANGE_MA_XEN
- load purgatory and modules into KEXEC_RANGE_MA_LIVEUPDATE
- append the Elf cmdline with " liveupdate=<size>@<addr>
v2: define xen related symbols outside of HAVE_LIBXENCTRL
Signed-off-by: Varad Gautam <vrd@amazon.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The modules may need to parse the arguments again after
kexec_file_load(2) failed, but getopt is not reset.
This change fixes the --initrd option on s390x. Without this patch,
it will fail to load the initrd on kernels that do not implement
kexec_file_load(2).
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The handling of kexec_file_load() error conditions needs some
improvement.
First, on failure, the system call itself returns -1 and sets
errno. It is wrong to check the return value itself.
Second, do_kexec_file_load() mixes different types of error
codes (-1, return value of a load method, negative kernel error
number). Let it always return one of the reason codes defined in
kexec/kexec.h.
Third, the caller of do_kexec_file_load() cannot know what exactly
failed inside that function, so it should not check errno directly.
All it needs to know is whether it makes sense to fall back to the
other syscall. Add an error code for that purpose (EFALLBACK), and
let do_kexec_file_load() decide.
Fourth, do_kexec_file_load() should not print any error message if
it returns EFALLBACK, because the fallback syscall may succeed
later, and the user is confused whether the command failed, or not.
Move the error message towards the end of main().
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently the kexec_file_load() support for arm64 doesn't allow
handling zlib compressed (i.e. Image.gz) image.
Since most distributions use 'make zinstall' rule inside
'arch/arm64/boot/Makefile' to install the arm64
Image.gz compressed file inside the boot destination directory (for e.g.
/boot), currently we cannot use kexec_file_load() to load vmlinuz (or
Image.gz):
# file /boot/vmlinuz
/boot/vmlinuz: gzip compressed data, was "Image", <..snip..>, max
compression, from Unix, original size 21945120
Now, since via kexec_file_load() we pass the 'fd' of Image.gz
(compressed file) via the following command line ...
# kexec -s -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
-r`.img --reuse-cmdline
... kernel returns -EINVAL error value, as it is not able to locate
the magic number =0x644d5241, which is expected in the 64-byte header
of the decompressed kernel image.
We can fix this in user-space kexec-tools, which handles an
'Image.gz' being passed via kexec_file_load(), using an approach
as follows:
a). Copy the contents of Image.gz to a temporary file.
b). Decompress (gunzip-decompress) the contents inside the
temporary file.
c). Pass the 'fd' of the temporary file to the kernel space. So
basically the kernel space still gets a decompressed kernel
image to load via kexec-tools
I tested this patch for the following three use-cases:
1. Uncompressed Image file:
#kexec -s -l Image --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline
2. Signed Image file:
#kexec -s -l Image.signed --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline
3. zlib compressed Image.gz file:
#kexec -s -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`.img --reuse-cmdline
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In kexec/kexec.c, we open() the kernel Image file and pass this file
descriptor to the kexec_file_load() system call, but never call a
corresponding close().
Fix the same via this patch.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add a new option --no-checks to kexec that allows for a fast
reboot by avoiding the purgatory integrity checks. This option is
intended for use by kexec based bootloaders that load a new
image and then immediately transfer control to it.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fixes warnings like these when building kexec for powerpc (32 bit):
kexec.c: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘uint64_t
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Do not fall through to "--mem-min" when "-p" option is parsed. The
break statement was apparently removed by mistake...
Fixes: cb434cbe6f40 ("kexec: Do not special-case the -s option")
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
supported
Not all architectures implement KEXEC_FILE_LOAD. However, on some
archiectures KEXEC_FILE_LOAD is required when secure boot is enabled in
locked-down mode. Previously users had to select the KEXEC_FILE_LOAD
syscall with undocumented -s option. However, if they did pass the
option kexec would fail on architectures that do not support it.
So add an -a option that tries KEXEC_FILE_LOAD and when it is not
supported tries KEXEC_LOAD.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The undocumented -s option selects KEXEC_FILE_LOAD syscall but there is
no option to select KEXEC_LOAD syscall. Add it so -s can be reverted.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
It is parsed separately to save a few CPU cycles when setting up other
options but it just complicates the code. So fold it back and set up all
flags for both KEXEC_LOAD and KEXEC_FILE_LOAD
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When kexec_file_load support was added some sanity checks were not updated.
Some options are set only in the kexec_load flags so cannot be supported
wiht kexec_file_load. On the other hand, reserved memory is needed for
kdump with both kexec_load and kexec_file_load.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When the kernel does not know a syscall number it returns -ENOSYS but
when kexec does not know a syscall number it returns -1. Return -ENOSYS
from kexec as well.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Crash kernel region size is available via sysfs on Linux running on
bare metal. However, this does not work when Linux runs as Xen dom0.
In this case Xen crash kernel region size should be established using
__HYPERVISOR_kexec_op hypercall (Linux kernel kexec functionality does
not make a lot of sense in Xen dom0). Sadly hypercalls are not easily
accessible using shell scripts or something like that. Potentially we
can check "xl dmesg" output for crashkernel option but this is not nice.
So, let's add this functionality, for Linux running on bare metal and
as Xen dom0, to kexec-tools. This way kdump scripts may establish crash
kernel region size in one way regardless of platform. All burden of
platform detection lies on kexec-tools.
Figure (and unit) displayed by this new kexec-tools functionality is
the same as one taken from /sys/kernel/kexec_crash_size.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Instead of the scripts having to poke at various fields we can
provide that functionality via the -S parameter.
kexec_loaded/kexec_crash_loaded exposes Linux kernel kexec/crash
state. It does not say anything about Xen kexec/crash state. So,
we need a special approach to get the latter. Though for
compatibility we provide similar functionality in kexec-tools
for the former.
This change enables the --status or -S option to work either
with or without Xen.
Returns 0 if the payload is loaded. Can be used in combination
with -l or -p to get the state of the proper kexec image.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Eric DeVolder <eric.devolder@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix warnings caused by selecting 64-bit file IO on 32-bit platforms.
kexec/kexec.c:710:2: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'off_t' [-Wformat]
kexec/zlib.c:63:4: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'off_t' [-Wformat]
kexec/kexec-uImage.c:85:3: warning: format '%ld' expects argument of type 'long
int', but argument 2 has type 'off_t' [-Wformat]
Acked-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit 8a1aa35a1077b42bc2a2afb05d24b637e1edf2a1.
|
|
Crash kernel region size is available via sysfs on Linux running on
bare metal. However, this does not work when Linux runs as Xen dom0.
In this case Xen crash kernel region size should be established using
__HYPERVISOR_kexec_op hypercall (Linux kernel kexec functionality does
not make a lot of sense in Xen dom0). Sadly hypercalls are not easily
accessible using shell scripts or something like that. Potentially we
can check "xl dmesg" output for crashkernel option but this is not nice.
So, let's add this functionality, for Linux running on bare metal and
as Xen dom0, to kexec-tools. This way kdump scripts may establish crash
kernel region size in one way regardless of platform. All burden of
platform detection lies on kexec-tools.
Figure (and unit) displayed by this new kexec-tools functionality is
the same as one taken from /sys/kernel/kexec_crash_size.
This functionality is available on x86 platform only. If idea is acceptable
then I can prepare patches for other platforms (if it is possible and make
sense) and repost them as fully flagged patch series.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When mmap fails, MAP_FAILED (that is, (void *) -1) is returned. Currently
we assume that NULL is returned. Fix this and add the MAP_FAILED check.
Fixes: 95741713e790 ("kexec/s390x: use mmap instead of read for slurp_file")
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
starting 'kexec -l /dev/mmcblk0p1' fails since the size of
a block device can not be determined with stat
Signed-off-by: Andreas Fenkart <andreas.fenkart@dev.digitalstrom.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The slurp_fd() function allocates memory and uses the read() system call.
This results in double memory consumption for image and initrd:
1) Memory allocated in user space by the kexec tool
2) Memory allocated in kernel by the kexec() system call
The following illustrates the use case that we have on s390x:
1) Boot a 4 GB Linux system
2) Copy kernel and 1,5 GB ramdisk from external source into tmpfs (ram)
3) Use kexec to boot kernel with ramdisk
Therefore for kexec runtime we need:
1,5 GB (tmpfs) + 1,5 GB (kexec malloc) + 1,5 GB (kernel memory) = 4,5 GB
This patch introduces slurp_file_mmap() which for "normal" files uses
mmap() instead of malloc()/read(). This reduces the runtime memory
consumption of the kexec tool as follows:
1,5 GB (tmpfs) + 1,5 GB (kernel memory) = 3 GB
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Reviewed-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit 7ab842d8a004f6cd75a9d7b3528e4a70819ce4ef.
using mmap by default in slurp_file cause segment fault while later
reallocing dtb_buf during my arm kexec test.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The slurp_fd() function allocates memory and uses the read() system call.
This results in double memory consumption for image and initrd:
1) Memory allocated in user space by the kexec tool
2) Memory allocated in kernel by the kexec() system call
Therefore use mmap() for non-character devices to reduce the runtime
memory consumption of the kexec tool.
The following use case illustrates the usefulness of this patch a bit more:
1) Boot a 4 GB Linux system
2) Read kernel and 1,5 GB ramdisk from external source into local tmpfs (ram)
3) kexec the kernel and ramdisk
Without this patch for the kexec runtime we need:
1,5 GB (tmpfs) + 1,5 GB (kexec malloc) + 1,5 GB (kernel memory) = 4,5 GB
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec --version reports like below:
kexec-tools 2.0.7 released 05 February 2015
The date string is generated when one run bootstrap script, thus
it is more like a build date instead of release date.
Even for distribution like Fedora it will make more sense if it can
report something like "kexec-tools 2.0.7-1 released 05 February 2015"
In case building from git tree, the date cause more confusion.
So let's remove it from version string unless there is better idea
to resolve the issue.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently, the two options must be the last ones to be honored;
otherwise, they can get silently ignored and both the manpage and help
text point it out. This is error-prone and trivial to fix. There
isn't much point in pointing something out in documentation when the
peculiarity can be removed with four lines of extra code.
Update option handling so that the two arguments are honored
regardless of their positions.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
During kernel develoment, kexec can be used to get out of sticky
situations without going through possibly lenghty reboot; however,
there are situations where the filesystem and/or storage stack are
known to be misbehaving and performing sync before kexecing is
dangerous or just never finishes.
This patch implement -y (--no-sync) option which makes kexec skip
syncing in the similar way as -x (--no-ifdown).
Signed-off-by: Tejun Heo <tj@kernel.org>
Suggested-by: Chris Mason <clm@fb.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This reverts commit 930f0c3734c223433e74037601cbfd1bc9df7bad.
|
|
panic_on_warn kernel parameter will cause the kernel to panic when a
WARN() is hit in the kernel. This is not a good situation for the kdump
kernel because then it would be possible for the kdump kernel to panic in
a non-fatal WARN().
This patch removes panic_on_warn as a kernel parameter for the kdump
kernel.
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: WANG Chao <chaowang@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
since we have already cleared kexec_info with memset,
there is no need to do that again to the struct members.
Signed-off-by: Hu Keping <hukeping@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently kexec returns success even if an invalid command line option
is encountered. Kexec currently prints usage message and then returns
0. That's not right. It is an error and error code 1 should be returned.
Due to this wrapper script thinks that kdump succeeded but that's not
the case.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Hi,
This is v2 of the patch. Since v1, I moved syscall implemented check littler
earlier in the function as per the feedback.
Now a new kexec syscall (kexec_file_load()) has been merged in upstream
kernel. This system call takes file descriptors of kernel and initramfs
as input (as opposed to list of segments to be loaded). This new system
call allows for signature verification of the kernel being loaded.
One use of signature verification of kernel is secureboot systems where
we want to allow kexec into a kernel only if it is validly signed by
a key system trusts.
This patch provides and option --kexec-file-syscall (-s), to force use of
new system call for kexec. Default is to continue to use old syscall.
Currently only bzImage64 on x86_64 can be loaded using this system call.
As kernel adds support for more arches and for more image types, kexec-tools
can be modified accordingly.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
dbgprint_mem_range is used for printing the given memory range under
debugging mode.
Signed-off-by: WANG Chao <chaowang@redhat.com>
Tested-by: Linn Crosetto <linn@hp.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix an off-by-one in locate_hole() that can cause it to return a range
that was previously allocated.
In upgrading to kexec-tools 2.0.5 I first got the error "Overlapping
memory segments at 0xbeff000"
Adding some debugging I found locate_hole was returning incorrect
values. The below is from the debug I added:
XXXMDF: look for hole size 100000, cur range [52b3000, bffffff] size 6d4cfff
XXXMDF: look for hole memsz=100000, found beff000
Hmm, if we wanted 0x100000 bytes ending at 0xbffffff, that should be
0xbf00000, not 0xbef000. Continuing to the second invocation:
XXXMDF: look for hole size 1000, cur range [52b3000, befefff] size 6c4bfff
XXXMDF: look for hole size 1000, cur range [bfff000, bffffff] size fff
XXXMDF: look for hole memsz=1000, found bffe000
Now we die with overlapping ranges, since the 0x100000 bytes at
0xbeff000 overlaps 0x1000 bytes at 0xbffe000.
Signed-off-by: Matthew Fleming <mdf356@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Currently kexec will use the kernel image type when probe function return
value >=0. It looks odd, but previously it works. Since commit bf06cf2095
it does not work anymore.
During my testing for arm zImage, in 2nd kernel the atags pointer and the
machine_id are not valid, I did a lot of debugging in kernel, finally I found
this is caused by a kexec tools bug instead.
Because uImage will be probed before zImage, also the uImage probe return 1
instead of -1 since bf06cf2095, thus kexec will mistakenly think it is uImage.
Fix this issue by regarding it's valid only when probe return 0.
Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Factor out the common part of slurp_file() and slurp_file_len() into
a new helper function slurp_fd().
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add an optional output parameter to slurp_file_len() so it can return the
actual number of bytes read.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
