summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-10-23arm64: Add purgatory printingMatthias Brugger
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>
2020-09-29kexec: Fix snprintf related compilation warningsBhupesh Sharma
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>
2020-09-29vmcore-dmesg/man page: Update the vmcore-dmesg man pageBhupesh Sharma
The vmcore-dmesg utility has been in usage for several years, and is pretty stable now. So its useful now to modify its man page to indicate the same. Also fix some minor formatting issues. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-09-29kexec-tools: Add some missing free() callsYouling Tang
Add some missing free() calls. Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-09-29kexec-tools: Fix a prompt message when crashkernel is not reservedYouling Tang
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>
2020-09-25kexec-tools: mips: Remove commandline parameter "mem"Youling Tang
"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>
2020-09-02kexec/kexec.c: Add missing close() callYouling Tang
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>
2020-09-02AUTHORS: Update email address for KhalidKhalid Aziz
New email address for Khalid Aziz. Signed-off-by: Khalid Aziz <khalid@gonehiking.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-08-20MIPS: Fix compile warnnings in kexec-elf-mips.cYouling Tang
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>
2020-08-10mips: kexec-elf-mips: fix not free in elf_mips_load()Jinyang He
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>
2020-08-10kexec-tools: Check callback first in kexec_iomem_for_each_line()Jinyang He
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>
2020-06-06arm: Increase zImage length after getting the tagŁukasz Stelmach
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>
2020-06-06kexec-tools: fix the unintended fallthrough when '-d' option is usedHari Bathini
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>
2020-04-24arm: redefine OPT_APPEND and OPT_RAMDISKŁukasz Stelmach
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>
2020-04-07kexec-tools: s390: Reset kernel command line on syscall fallbackPetr Tesarik
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>
2020-04-07kexec-xen: Introduce --exec-live-update to trigger a live updateVarad Gautam
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>
2020-04-07kexec: Introduce --load-live-update for xenVarad Gautam
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>
2020-04-07kexec-xen: Introduce xen_get_kexec_range to wrap xc_kexec_get_rangeVarad Gautam
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>
2020-04-01kexec-tools: Remove duplicated variable declarationsKairui Song
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>
2020-04-01Removing condition that will never be met after calls xmalloc and xreallocLeonidas S. Barbosa
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>
2020-04-01kexec: support parsing the string "Reserved" to get the correct e820 ↵Lianbo Jiang
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>
2020-04-01kexec-tools: Reset getopt before falling back to legacy syscallPetr Tesarik
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>
2020-04-01kexec-tools: Fix kexec_file_load(2) error handlingPetr Tesarik
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>
2020-04-01crashdump-ppc64: crashkernel-base and crashkernel-size are big-endianThadeu Lima de Souza Cascardo
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>
2020-01-03kexec: build multiboot2 for i386Chris Packham
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>
2020-01-03ARM: Use mmap for zImage initrdBrandon Maier
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>
2020-01-03arm64: kdump: deal with a lot of resource entries in /proc/iomemAKASHI Takahiro
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>
2020-01-03arm64: kexec: allocate memory space avoiding reserved regionsAKASHI Takahiro
On UEFI/ACPI-only system, some memory regions, including but not limited to UEFI memory map and ACPI tables, must be preserved across kexec'ing. Otherwise, they can be corrupted and result in early failure in booting a new kernel. In recent kernels, /proc/iomem now has an extended file format like: 40000000-5871ffff : System RAM 41800000-426affff : Kernel code 426b0000-42aaffff : reserved 42ab0000-42c64fff : Kernel data 54400000-583fffff : Crash kernel 58590000-585effff : reserved 58700000-5871ffff : reserved 58720000-58b5ffff : reserved 58b60000-5be3ffff : System RAM 58b61000-58b61fff : reserved where the "reserved" entries at the top level or under System RAM (and its descendant resources) are ones of such kind and should not be regarded as usable memory ranges where several free spaces for loading kexec data will be allocated. With this patch, get_memory_ranges() will handle this format of file correctly. Note that, for safety, unknown regions, in addition to "reserved" ones, will also be excluded. 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>
2020-01-03kexec: add variant helper functions for handling memory regionsAKASHI Takahiro
mem_regions_alloc_and_add() and mem_regions_alloc_and_exclude() are functionally equivalent to, respectively, mem_regions_add() and mem_regions_exclude() except the formers will re-allocate memory dynamically when no more entries are available in 'ranges' array. 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>
2019-10-07kexec-tools: Fix conversion overflow when compiling on 32-bit platformsHelge Deller
When compiling kexec-tools on a 32-bit platform, assigning an (unsigned long long) value to an (unsigned long) variable creates this warning: elf_info.c: In function 'read_phys_offset_elf_kcore': elf_info.c:805:14: warning: conversion from 'long long unsigned int' to 'long unsigned int' changes value from '18446744073709551615' to '4294967295' 805 | *phys_off = UINT64_MAX; Fix it by using ULONG_MAX instead of UINT64_MAX. Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-10-03kexec-tools: Fix possible out-of-bounds access in ifdownHelge Deller
Fix a possible out-of-bounds access in function ifdown(): ifdown.c: In function 'ifdown': ifdown.c:56:4: warning: 'strncpy' specified bound 16 equals destination size [-Wstringop-truncation] 56 | strncpy(ifr.ifr_name, ifp->if_name, IFNAMSIZ); Signed-off-by: Helge Deller <deller@gmx.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-10-01kexec: add support for PARISC architectureSven Schnelle
This patch adds support for the parisc Architecture. kexec support for parisc is included with linux-5.4. Signed-off-by: Sven Schnelle <svens@stackframe.org> Tested-by: Helge Deller <deller@gmx.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-16kexec/arm: undefine __NR_kexec_file_load for armQuanyang Wang
In the kernel upstream commit 4ab65ba7a5cb ("ARM: add kexec_file_load system call number"), __NR_kexec_file_load for arm has been defined to be 401. This results that even if kexec_file_load isn't implemented for arm but the function is_kexec_file_load_implemented() will still return true. So undef __NR_kexec_file_load for arm architecture. Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-16i386/kexec-mb2-x86.c: Fix compilation warningBhupesh Sharma
This patch fixes the following compilation warning in 'i386/kexec-mb2-x86.c' regarding the variable 'result' which is set but not used: kexec/arch/i386/kexec-mb2-x86.c:402:6: warning: variable ‘result’ set but not used [-Wunused-but-set-variable] int result; ^~~~~~ Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-16vmcore-dmesg/vmcore-dmesg.c: Fix shifting error reported by cppcheckBhupesh Sharma
Running 'cppcheck' static code analyzer (see cppcheck(1)) on 'vmcore-dmesg/vmcore-dmesg.c' shows the following shifting error: $ cppcheck --enable=all vmcore-dmesg/vmcore-dmesg.c Checking vmcore-dmesg/vmcore-dmesg.c ... [vmcore-dmesg/vmcore-dmesg.c:17]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour Fix the same via this patch. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-08Limit the size of vmcore-dmesg.txt to 2GLianbo Jiang
With some corrupted vmcore files, the vmcore-dmesg.txt file may grow forever till the kdump disk becomes full, and also probably causes the disk error messages as follow: ... sd 0:0:0:0: [sda] tag#6 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#6 CDB: Read(10) 28 00 08 06 4c 98 00 00 08 00 blk_update_request: I/O error, dev sda, sector 134630552 sd 0:0:0:0: [sda] tag#7 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK sd 0:0:0:0: [sda] tag#7 CDB: Read(10) 28 00 08 06 4c 98 00 00 08 00 blk_update_request: I/O error, dev sda, sector 134630552 ... If vmcore-dmesg.txt occupies the whole disk, the vmcore can not be saved, this is also a problem. Lets limit the size of vmcore-dmesg.txt to avoid such problems. Signed-off-by: Lianbo Jiang <lijiang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-08Cleanup: move it back from util_lib/elf_info.cLianbo Jiang
Some code related to vmcore-dmesg.c is put into the util_lib, which is not very reasonable, so lets move it back and tidy up those code. In addition, that will also help to limit the size of vmcore-dmesg.txt in vmcore-dmesg.c instead of elf_info.c. Signed-off-by: Lianbo Jiang <lijiang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-08Fix an error definition about the variable 'fname'Lianbo Jiang
The variable 'fname' is mistakenly defined two twice, the first definition is in the vmcore-dmesg.c, and the second definition is in the elf_info.c. That is confused and incorrect although it's a static type, because the value of variable 'fname' is not assigned(set) in elf_info.c. Anyway, its value will be always 'null' when printing an error information. Signed-off-by: Lianbo Jiang <lijiang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-08Cleanup: remove the read_elf_kcore()Lianbo Jiang
Here, no need to wrap the read_elf() again, lets invoke it directly. So remove the read_elf_kcore() and clean up redundant code. Signed-off-by: Lianbo Jiang <lijiang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-03x86: Fix PAGE_OFFSET for kernels since 4.20Donald Buczek
Linux kernel commit d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging") changed the base of the direct mapping from 0xffff880000000000 to 0xffff888000000000. This was merged into v4.20-rc2. Update to new address accordingly. Signed-off-by: Simon Horman <horms@verge.net.au>
2019-09-03kexec-tools 2.0.20.gitSimon Horman
Add .git to version so it doesn't look like a release. This is just so when people build code from git it can be identified as such from the version string. Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-25kexec-tools 2.0.20Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-16kexec-tools 2.0.20-rc2Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-16kexec/arm64: Add support for handling zlib compressed (Image.gz) imageBhupesh Sharma
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>
2019-07-16kexec/kexec-zlib.h: Add 'is_zlib_file()' helper functionBhupesh Sharma
This patch adds 'is_zlib_file()' helper function which can be used to quickly determine with the passed kernel image is a zlib compressed kernel image. This is specifically useful for arm64 zImage (or Image.gz) support, which is introduced by later patches in this patchset. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-16kexec-uImage-arm64.c: Fix return value of uImage_arm64_probe()Bhupesh Sharma
Commit bf06cf2095e1 ("kexec/uImage: probe to identify a corrupted image"), defined the 'uImage_probe_kernel()' function return values and correspondingly ;uImage_arm64_probe()' returns the same (0 -> If the image is valid 'type' image, -1 -> If the image is corrupted and 1 -> If the image is not a uImage). This causes issues because, in later patches we introduce zImage support for arm64, and since it is probed after uImage, the return values from 'uImage_arm64_probe()' needs to be fixed to make sure that kexec will not return with an invalid error code. Now, 'uImage_arm64_probe()' returns the following values instead: 0 - valid uImage. -1 - uImage is corrupted. 1 - image is not a uImage. Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-16kexec/kexec.c: Add the missing close() for fd used for kexec_file_load()Bhupesh Sharma
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>
2019-07-10kexec-tools 2.0.20-rc1Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-10x86: Include kexec-mb2-x86.c and multiboot2.h in distributionSimon Horman
Fixes: 22a2ed55132e ("x86: Support multiboot2 images") Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-03x86: re-order includes to avoid duplicate struct e820entrySimon Horman
xenctrl.h defines struct e820entry as: if defined(__i386__) || defined(__x86_64__) ... #define E820_RAM 1 ... struct e820entry { uint64_t addr; uint64_t size; uint32_t type; } __attribute__((packed)); ... #endif $ dpkg-query -S /usr/include/xenctrl.h libxen-dev:amd64: /usr/include/xenctrl.h $ dpkg-query -W libxen-dev:amd64 libxen-dev:amd64 4.8.5+shim4.10.2+xsa282-1+deb9u11 ./include/x86/x86-linux.h defines struct e820entry as: #ifndef E820_RAM struct e820entry { uint64_t addr; /* start of memory segment */ uint64_t size; /* size of memory segment */ uint32_t type; /* type of memory segment */ #define E820_RAM 1 ... } __attribute__((packed)); #endif Since cedeee0a3007 ("x86: Introduce helpers for getting RSDP address") ./kexec/arch/i386/kexec-x86-common.c includes +#include "x86-linux-setup.h" #include "../../kexec-xen.h" When xenctrl.h is present the above results in: $ gcc ... In file included from kexec/arch/i386/../../kexec-xen.h:5:0, from kexec/arch/i386/kexec-x86-common.c:43: /usr/include/xenctrl.h:1271:8: error: redefinition of 'struct e820entry' struct e820entry { ^~~~~~~~~ In file included from kexec/arch/i386/x86-linux-setup.h:3:0, from kexec/arch/i386/kexec-x86-common.c:42: ./include/x86/x86-linux.h:16:8: note: originally defined here struct e820entry { ^~~~~~~~~ ... $ gcc --version | head -1 gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 To militate this this problem re-order the includes so that x86-linux.h is included after xenctrl.h and thus struct e820entry will only be defined once due to it being devined conditionally in x86-linux.h. In practice the definitions are the same so it should not matter which is chosen. It also seems rather unpleasent to me to need to play with include ordering. Perhaps a better solution in the longer term would be to rename the local definition of struct e820entry. Fixes: cedeee0a3007 ("x86: Introduce helpers for getting RSDP address") Signed-off-by: Simon Horman <horms@verge.net.au>
generated by cgit (git 2.34.1) at 2025-07-16 09:59:14 +0000