| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Zhaofeng Li <hello@zhaofeng.li>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Replace hardcoded FDT structure block tokens with proper names to
improve code readability.
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Since kernel commit e2a073dde921 ("arm64: omit [_text, _stext) from
permanent kernel mapping"), the physical address of 'Kernel code' in
/proc/iomem is mapped from _text, instead, from _stext.
Taking the compatibility into account, it had better deduce the paddr of
_text despite of the unavailability through /proc/iomem. It can be
achieved by utilizing the fact _text aligned on 2MB.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Cc: Simon Horman <horms@verge.net.au>
To: kexec@lists.infradead.org
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The ramdisk variable is defined in kexec/arch/ppc/kexec-ppc.c. This
other definition is not needed and breaks build with -fno-common.
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
If the passed zImage happens to have a DTB appended, then the magic 4 bytes
of the DTB are copied together with the kernel image. This leads to
failed kexec boots because the decompressor finds the aforementioned
DTB magic and falsely tries to replace the DTB passed in the register r2
with the non-existent appended one.
Signed-off-by: Alexander Egorenkov <egorenar-dev@posteo.net>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
During kexec there are two kernel versions at play. The version of
the running kernel and the version of the kernel that will be booted.
On powerpc it appears people have been using the version of the
running kernel to attempt to detect properties of the kernel to be
booted which is just wrong. As the linux kernel version that is being
detected is a no longer supported kernel just remove that buggy and
confused code.
On x86_64 the kernel_version is used to compute the starting virtual
address of the running kernel so a proper core dump may be generated.
Using the kernel_version stopped working a while ago when the starting
virtual address became randomized.
The old code was kept for the case where the kernel was not built with
randomization support, but there is nothing in reading /proc/kcore
that won't work to detect the starting virtual address even there.
In fact /proc/kcore must have the starting virtual address or a
debugger can not make sense of the running kernel.
So just make computing the starting virtual address on x86_64
unconditional. With a hard coded fallback just in case something went
wrong.
Doing something with kernel_version() has become important as recent
stable kernels have seen the minor version to > 255. Just removing
kernel_version() looks like the best option.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We risk throwing an entire large chunk away if it is just slightly
unaligned which then causes the crash kernel to run out of RAM. Keep
them and shrink them to alignment.
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The real mode ends at 0x400, not 0x100. The code intentionally excludes
the IVT as RAM, so use the correct address.
Also, 0x100 is not 1K aligned and will be rejected by add_memmap(). We
have observed problems that after a multiboot2 kexec, the next kexec
will throw away such unaligned chunks, losing memory for the next next
kernel. In some corner cases, such loss of memory can actually cause OOM
during boot.
Signed-off-by: Hongyan Xia <hongyxia@amazon.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
virtio-mem in Linux adds/removes individual memory blocks (e.g., 128 MB
each). Linux merges adjacent memory blocks added by virtio-mem devices, but
we can still end up with a very sparse memory layout when unplugging
memory in corner cases.
Let's increase the maximum number of crash memory ranges from ~2k to 32k.
32k should be sufficient for a very long time.
e_phnum field in the header is 16 bits wide, so we can fit a maximum of
~64k entries in there, shared with other entries (i.e., CPU). Therefore,
using up to 32k memory ranges is fine. (if we ever need more than ~64k,
we can switch to the sh_info field)
Move the temporary xen ranges off the stack, dynamically allocating
memory for them.
Note: We don't have to increase MAX_MEMORY_RANGES, because virtio-mem
added memory is driver managed and always detected and added by a
driver in the kexec'ed kernel; for ordinary kexec, we must not expose
these ranges in the firmware-provided memmap.
Cc: Simon Horman <horms@verge.net.au>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
No need to iterate over empty entries.
Cc: Simon Horman <horms@verge.net.au>
Signed-off-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Traditionally, we had "System RAM" only on the top level of in the
kernel resource tree (-> /proc/iomem). Nowadays, we can also have
"System RAM" on lower levels of the tree -- driver-managed device memory
that is always detected and added via drivers. Current examples are
memory added via dax/kmem -- ("System RAM (kmem)") and virtio-mem ("System
RAM (virtio_mem)"). Note that in some kernel versions "System RAM
(kmem)" was exposed as "System RAM", but similarly, on lower levels of
the resource tree.
Let's add anything that contains "System RAM" to the elf core header, so
it will be dumped for kexec_load(). Handling kexec_file_load() in the
kernel is similarly getting fixed [1].
Loading a kdump kernel via "kexec -p -c" ... will result in the kdump
kernel to also dump dax/kmem and virtio-mem added System RAM now.
Note: We only want to dump this memory, we don't want to add this memory to
the memmap of an ordinary kexec'ed kernel ("fast system reboot").
[1] https://lkml.kernel.org/r/20210322160200.19633-1-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Unlike xen_kexec_load(), xen_kexec_unload() and xen_kexec_status()
fail to distinguish between normal kexec and Xen Live Update image
types.
Fix that by introducing a new helper function that maps internal
flags to KEXEC_TYPE_*, and using it throughout kexec-xen.c.
Signed-off-by: Raphael Ning <raphning@amazon.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>
|
|
The added "mem=size@start" parameter actually corresponds to
"crashkernel=YM@XM", but 1 byte is missing when calculating
the size, so 1 byte should be added.
For example, when using crashkernel=108M@64M (110592K@65536K):
Without this patch:
the mem parameter added is: mem=110591K@65536K
With this patch:
the mem parameter added is: mem=110592K@65536K
Fixes: 0eac64052636 ("kexec: mips: Fix mem parameters")
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
kexec build will fail on older kernels (pre 4.4) as the define
VIDEO_CAPABILITY_64BIT_BASE was not present at that time.
This patch adds it, as per linux/include/uapi/linux/screen_info.h,
if not present.
Signed-off-by: Federico Pellegrin <fede@evolware.org>
Reviewed-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Fix typo in comment.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch adds an option "--reuse-cmdline" for people that are lazy
in typing --append="$(cat /proc/cmdline)", which will directly use the
command line of the currently running system.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
"mem=" is useful to indicate the memory region when capture kernel boot.
Otherwise, capture kernel will breakdown the memory of panic kernel.
Although it can be add by user, adding "mem" by software is a better way.
What's more, "mem" should contain elfcorehdr range. Elfcorehdr memory
should be managed by kernel.
Fixes: 7bd251654aad ("kexec-tools: mips: Remove commandline parameter "mem"")
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In function dtb_set_property, when malloc new_node fails,
we need to free new_dtb before return.
Fixes: f56cbcf4c2766 ("kexec/dt-ops.c: Fix '/chosen' v/s 'chosen' node
being passed to fdt helper functions")
Signed-off-by: qiuguorui1 <qiuguorui1@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In function zlib_decompress_file, when gzdirect(fp) fails,
we should gzclose fp before return.
Fixes: d606837b56d46 ("Fix zlib/lzma decompression.")
Signed-off-by: qiuguorui1 <qiuguorui1@huawei.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
fixed the same way as in 70cca82
"kexec: Fix snprintf related compilation warnings"
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add option to allow purgatory printing on arm64 hardware
by passing the console name which should be used.
Based on a patch by Geoff Levand.
Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This patch fixes the following snprintf related compilation warning
seen currently with gcc versions 7 and 8 when kexec is compiled with
-Wformat-truncation option:
kexec/fs2dt.c:673:34: warning: ‘stdout-path’ directive output may be truncated writing 11 bytes into a region of size between 1 and 1024 [-Wformat-truncation=]
snprintf(filename, MAXPATH, "%sstdout-path", pathname);
^~~~~~~~~~~
kexec/fs2dt.c:673:3: note: ‘snprintf’ output between 12 and 1035 bytes into a destination of size 1024
snprintf(filename, MAXPATH, "%sstdout-path", pathname);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kexec/fs2dt.c:676:35: warning: ‘linux,stdout-path’ directive output may be truncated writing 17 bytes into a region of size between 1 and 1024 [-Wformat-truncation=]
snprintf(filename, MAXPATH, "%slinux,stdout-path", pathname);
^~~~~~~~~~~~~~~~~
kexec/fs2dt.c:676:4: note: ‘snprintf’ output between 18 and 1041 bytes into a destination of size 1024
snprintf(filename, MAXPATH, "%slinux,stdout-path", pathname);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kexec/firmware_memmap.c:132:35: warning: ‘%s’ directive output may be truncated writing 5 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
snprintf(filename, PATH_MAX, "%s/%s", entry, "start");
^~ ~~~~~~~
kexec/firmware_memmap.c:132:2: note: ‘snprintf’ output between 7 and 4102 bytes into a destination of size 4096
snprintf(filename, PATH_MAX, "%s/%s", entry, "start");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kexec/firmware_memmap.c:142:35: warning: ‘%s’ directive output may be truncated writing 3 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
snprintf(filename, PATH_MAX, "%s/%s", entry, "end");
^~ ~~~~~
kexec/firmware_memmap.c:142:2: note: ‘snprintf’ output between 5 and 4100 bytes into a destination of size 4096
snprintf(filename, PATH_MAX, "%s/%s", entry, "end");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kexec/firmware_memmap.c:152:35: warning: ‘%s’ directive output may be truncated writing 4 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
snprintf(filename, PATH_MAX, "%s/%s", entry, "type");
^~ ~~~~~~
kexec/firmware_memmap.c:152:2: note: ‘snprintf’ output between 6 and 4101 bytes into a destination of size 4096
snprintf(filename, PATH_MAX, "%s/%s", entry, "type");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Since the simplest method to address the gcc warnings and possible
truncation would be to check the return value provided from snprintf
(well there are other methods like using 'asnprintf' or using
'open_memstream' function to create the FILE object, but these are more
intrusive), so this patch does the same.
Cc: Simon Horman <horms@verge.net.au>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: kexec@lists.infradead.org
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Add some missing free() calls.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
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>
|
|
"mem=" indicating the memory region the new kernel can use to boot into.
And passed to the dump-capture kernel by kernel commandline parameter
"mem=". But in the dump-capture kernel, we don’t need to use this parameter
now, so remove "mem" and don't add "mem=" to new kernel commandline.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
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>
|
|
Fix the following warnings:
kexec/arch/mips/kexec-elf-mips.c:161:41: warning: passing argument 3 of
‘dtb_set_initrd’ makes integer from pointer without a cast
dtb_set_initrd(&dtb_buf, &dtb_length, initrd_buf, initrd_buf + initrd_size);
^
In file included from kexec/arch/mips/kexec-elf-mips.c:33:0:
kexec/arch/mips/../../dt-ops.h:6:5: note: expected ‘off_t’ but argument is
of type ‘char *’
int dtb_set_initrd(char **dtb, off_t *dtb_size, off_t start, off_t end);
^
kexec/arch/mips/kexec-elf-mips.c:161:53: warning: passing argument 4 of
‘dtb_set_initrd’ makes integer from pointer without a cast
dtb_set_initrd(&dtb_buf, &dtb_length, initrd_buf, initrd_buf + initrd_size);
^
In file included from kexec/arch/mips/kexec-elf-mips.c:33:0:
kexec/arch/mips/../../dt-ops.h:6:5: note: expected ‘off_t’ but argument is
of type ‘char *’
int dtb_set_initrd(char **dtb, off_t *dtb_size, off_t start, off_t end);
^
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In the function elf_mips_load(), crash_cmdline was alloced memory.
But it seems to forget to free it when last used at line 131.
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
In the function kexec_iomem_for_each_line(), it is better to
check the callback first, it can return directly if the callback
is NULL.
Signed-off-by: Jinyang He <hejinyang@loongson.cn>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Increase the size of the zImage after seeking for the tag to avoid
reading past the end of the supplied buffer should there be not tag
in the zImage.
Fixes: f57f0bf8975d24fe1e7c4936fdfb5c3b123ab75f
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Cc: Russell King <rmk@armlinux.org.uk>
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>
|
|
Redefine OPT_APPEND to avoid clash with OPT_KEXEC_SYSCALL_AUTO.
Redefine OPT_RAMDISK to avoid such problems in the future
Minor cleanup in HPPA too.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
The command line is duplicated on s390 if kexec_file_load(2) is not
implemented. That's because the corresponding variable is not reset
to an empty string before re-parsing the kexec command line.
Fixes: 9cf721279f6c ("Reset getopt before falling back to legacy syscall")
Signed-off-by: Petr Tesarik <ptesarik@suse.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>
|
|
And convert all callers of xc_kexec_get_range to use this. Allows reusing
sanity checks for other KEXEC_RANGEs
v2: define xen_get_kexec_range outside of HAVE_LIBXENCTRL
Signed-off-by: Varad Gautam <vrd@amazon.de>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
When building kexec-tools for Fedora 32, following error is observed:
/usr/bin/ld: kexec/arch/x86_64/kexec-bzImage64.o:(.bss+0x0): multiple definition of `bzImage_support_efi_boot';
kexec/arch/i386/kexec-bzImage.o:(.bss+0x0): first defined here
/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm/../../fs2dt.h:33: multiple definition of `my_debug';
kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/kexec/fs2dt.h:33: first defined here
/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:68: multiple definition of `arm64_mem';
kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:68: first defined here
/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:54: multiple definition of `initrd_size';
kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:54: first defined here
/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:53: multiple definition of `initrd_base';
kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:53: first defined here
And apparently, these variables are wrongly declared multiple times. So
remove duplicated declaration.
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
Hi,
Looking in the kexec-tools code I found these conditions that
seems will never be met. Not sure if that was intentional for explicitity,
if it was the case, please disconsider this patch.
xmalloc and xrealloc when fails calls die() that calls exit(1).
Checks for if(!memory) after they are called will never be met that
condition, since the process will be exited after an allocation fail.
Signed-off-by: Leonidas S. Barbosa <kirotawa@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
reserved region
When loading kernel and initramfs for kexec, kexec-tools could get the
e820 reserved region from "/proc/iomem" in order to rebuild the e820
ranges for kexec kernel, but there may be the string "Reserved" in the
"/proc/iomem", which caused the failure of parsing. For example:
#cat /proc/iomem|grep -i reserved
00000000-00000fff : Reserved
7f338000-7f34dfff : Reserved
7f3cd000-8fffffff : Reserved
f17f0000-f17f1fff : Reserved
fe000000-ffffffff : Reserved
Currently, kexec-tools can not handle the above case because the memcmp()
is case sensitive when comparing the string.
So, let's fix this corner and make sure that the string "reserved" and
"Reserved" in the "/proc/iomem" are both parsed appropriately.
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Bhupesh Sharma <bhsharma@redhat.com>
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>
|
|
When reading the device-tree exported crashkernel-base and
crashkernel-size, their values should be converted from big-endian to the
CPU byte order.
These is the output of running kexec --print-ckr-size on a little-endian
ppc64 box.
$ kexec --print-ckr-size
137438953472
$ kexec --print-ckr-size
536870912
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
This addresses the following compilation issues when building for i386.
kexec/arch/i386/kexec-x86.c:39:22: error: 'multiboot2_x86_probe' undeclared here (not in a function); did you mean 'multiboot_x86_probe'?
{ "multiboot2-x86", multiboot2_x86_probe, multiboot2_x86_load,
^~~~~~~~~~~~~~~~~~~~
multiboot_x86_probe
kexec/arch/i386/kexec-x86.c:39:44: error: 'multiboot2_x86_load' undeclared here (not in a function); did you mean 'multiboot_x86_load'?
{ "multiboot2-x86", multiboot2_x86_probe, multiboot2_x86_load,
^~~~~~~~~~~~~~~~~~~
multiboot_x86_load
kexec/arch/i386/kexec-x86.c:40:4: error: 'multiboot2_x86_usage' undeclared here (not in a function); did you mean 'multiboot_x86_usage'?
multiboot2_x86_usage },
^~~~~~~~~~~~~~~~~~~~
multiboot_x86_usage
make: *** [Makefile:114: kexec/arch/i386/kexec-x86.o] Error 1
make: *** Waiting for unfinished jobs....
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
We use a large initrd that maxes out our available RAM when loading
kexec. The problem can be mitigated by using slurp_file_mmap(), which
avoids creating a copy of the initrd. The initrd does not use free,
realloc, etc, so it should be safe to use.
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
|
As described in the commit ("arm64: kexec: allocate memory space avoiding
reserved regions"), /proc/iomem now has a lot of "reserved" entries, and
it's not just enough to have a fixed size of memory range array.
With this patch, kdump is allowed to handle arbitrary number of memory
ranges, using mem_regions_alloc_and_xxx() functions.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Tested-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
|
