summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2024-04-26ARM: Fix add_buffer_phys_virt() align issueHEADmastermainHaiqing Bai1-1/+4
When "CONFIG_ARM_LPAE" is enabled,3 level page table is used by MMU, the "SECTION_SIZE" is defined with (1 << 21), but 'add_buffer_phys_virt()' hardcode this to (1 << 20). Suggested-By: fredrik.markstrom@gmail.com Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com> Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Simon Horman <horms@kernel.org>
2024-04-23Fix incorrect Free Software Foundation address in the licenseCoiby Xu1-23/+21
As detected by rpmlint, kexec-tools.x86_64: E: incorrect-fsf-address /usr/share/licenses/kexec-tools/COPYING The Free Software Foundation address in this file seems to be outdated or misspelled. Ask upstream to update the address, or if this is a license file, possibly the entire file with a new copy available from the FSF. Replace current one with https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt to fix this issue. Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Simon Horman <horms@kernel.org>
2024-03-22util_lib/elf_info.c: fix a warningBaoquan He1-1/+1
There's a incorrect array operation in function scan_vmcoreinfo(), it will cause below warning message. ----------------------- util_lib/elf_info.c: In function ‘scan_vmcoreinfo’: util_lib/elf_info.c:360:43: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 360 | temp_buf[len + 1] = '\0'; | ~~~~~~~~~~~~~~~~~~^~~~~~ util_lib/elf_info.c:319:14: note: at offset 1024 into destination object ‘temp_buf’ of size 1024 319 | char temp_buf[1024]; | ^~~~~~~~ --------------------- Fix it to avoid oob access of array. Signed-off-by: Baoquan He <bhe@redhat.com> Signed-off-by: Simon Horman <horms@kernel.org>
2024-03-15kexec_file: add kexec_file flag to support debug printingBaoquan He2-0/+2
This add KEXEC_FILE_DEBUG to kexec_file_flags so that it can be passed to kernel when '-d' is added with kexec_file_load interface. With that flag enabled, kernel can enable the debugging message printing. Signed-off-by: Baoquan He <bhe@redhat.com> Signed-off-by: Simon Horman <horms@kernel.org>
2024-02-07workflow: update to use checkout@v4Simon Horman1-1/+1
Update to use checkout@v4. This addresses the following warning that appears in GitHub runs: "Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/. Link: https://github.com/horms/kexec-tools/actions/runs/7753454923 Signed-off-by: Simon Horman <horms@kernel.org>
2024-02-02Fix building on x86_64 with binutils 2.41Michel Lind4-4/+4
Newer versions of the GNU assembler (observed with binutils 2.41) will complain about the ".arch i386" in files assembled with "as --64", with the message "Error: 64bit mode not supported on 'i386'". Fix by moving ".arch i386" below the relevant ".code32" directive, so that the assembler is no longer expecting 64-bit instructions to be used by the time that the ".arch i386" directive is encountered. Based on similar iPXE fix: https://github.com/ipxe/ipxe/commit/6ca597eee Signed-off-by: Michel Lind <michel@michel-slm.name> Signed-off-by: Simon Horman <horms@kernel.org>
2024-01-25kexec: don't use kexec_file_load on XENJiri Bohac2-0/+5
Since commit 29fe5067ed07 ("kexec: make -a the default") kexec tries the kexec_file_load syscall first and only falls back to kexec_load on selected error codes. This effectively breaks kexec on XEN, unless -c is pecified to force the kexec_load syscall. The XEN-specific functions (xen_kexec_load / xen_kexec_unload) are only called from my_load / k_unload, i.e. the kexec_load code path. With -p (panic kernel) kexec_file_load on XEN fails with -EADDRNOTAVAIL (crash kernel reservation is ignored by the kernel on XEN), which is not in the list of return codes that cause the fallback to kexec_file. Without -p kexec_file_load actualy leads to a kernel oops on v6.4.0 (needs to be dubugged separately). Signed-off-by: Jiri Bohac <jbohac@suse.cz> Fixes: 29fe5067ed07 ("kexec: make -a the default") Signed-off-by: Simon Horman <horms@kernel.org>
2024-01-25kexec-tools 2.0.28.gitSimon Horman1-1/+1
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@kernel.org>
2024-01-11kexec-tools 2.0.28v2.0.28Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@kernel.org>
2024-01-03kexec-tools 2.0.28-rc1v2.0.28-rc1Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@kernel.org>
2023-12-02LoongArch: Load vmlinux.efi to the link addressWANG Rui1-3/+7
Currently, kexec loads vmlinux.efi to address 0 instead of the link address. This causes kexec to fail to boot the new vmlinux.efi on qemu. pei_loongarch_load: kernel_segment: 0000000000000000 pei_loongarch_load: kernel_entry: 00000000013f1000 pei_loongarch_load: image_size: 0000000001ca0000 pei_loongarch_load: text_offset: 0000000000200000 pei_loongarch_load: phys_offset: 0000000000000000 pei_loongarch_load: PE format: yes loongarch_load_other_segments:333: command_line: kexec console=ttyS0,115200 kexec_load: entry = 0x13f1000 flags = 0x1020000 nr_segments = 2 segment[0].buf = 0x7fffeea38010 segment[0].bufsz = 0x1b55200 segment[0].mem = (nil) segment[0].memsz = 0x1ca0000 segment[1].buf = 0x5555570940b0 segment[1].bufsz = 0x200 segment[1].mem = 0x1ca0000 segment[1].memsz = 0x4000 This patch constrains the range of the kernel segment by `hole_min` and `hole_max` to place vmlinux.efi exactly at the link address. pei_loongarch_load: kernel_segment: 0000000000200000 pei_loongarch_load: kernel_entry: 00000000013f1000 pei_loongarch_load: image_size: 0000000001ca0000 pei_loongarch_load: text_offset: 0000000000200000 pei_loongarch_load: phys_offset: 0000000000000000 pei_loongarch_load: PE format: yes loongarch_load_other_segments:339: command_line: kexec console=ttyS0,115200 kexec_load: entry = 0x13f1000 flags = 0x1020000 nr_segments = 2 segment[0].buf = 0x7ffff2028010 segment[0].bufsz = 0x1b55200 segment[0].mem = 0x200000 segment[0].memsz = 0x1ca0000 segment[1].buf = 0x555557498098 segment[1].bufsz = 0x200 segment[1].mem = 0x1ea0000 segment[1].memsz = 0x4000 Signed-off-by: WANG Rui <wangrui@loongson.cn> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
2023-12-02LoongArch: Fix an issue with relocatable vmlinuxWANG Rui1-2/+3
Normally vmlinux for LoongArch is of ET_EXEC type, while if built with CONFIG_RELOCATABLE (this is PIE) and Clang, it will be of ET_DYN type. Meanwhile, physical address field of segments in vmlinux has actually the same value as virtual address field. Similar to arm64, this patch allows to unconditionally skip the check on LoongArch. Link: https://github.com/ClangBuiltLinux/linux/issues/1963 Signed-off-by: WANG Rui <wangrui@loongson.cn> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
2023-12-02m68k: fix getrandom() use with uclibcLaurent Vivier1-0/+1
With uclibc, getrandom() is only defined with _GNU_SOURCE, fix that: kexec/arch/m68k/bootinfo.c: In function 'bootinfo_add_rng_seed': kexec/arch/m68k/bootinfo.c:231:13: warning: implicit declaration of function 'getrandom'; did you mean 'srandom'? [-Wimplicit-function-declaration] 231 | if (getrandom(bi->rng_seed.data, RNG_SEED_LEN, GRND_NONBLOCK) != RNG_SEED_LEN) { | ^~~~~~~~~ | srandom kexec/arch/m68k/bootinfo.c:231:56: error: 'GRND_NONBLOCK' undeclared (first use in this function) 231 | if (getrandom(bi->rng_seed.data, RNG_SEED_LEN, GRND_NONBLOCK) != RNG_SEED_LEN) { | ^~~~~~~~~~~~~ Fixes: b9de05184816 ("m68k: pass rng seed via BI_RNG_SEED") Cc: Jason@zx2c4.com Signed-off-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Simon Horman <horms@kernel.org>
2023-12-02lzma: Relax memory limit for lzma decompressorWANG Rui1-1/+1
The kexec cannot load LZMA compressed vmlinuz.efi on LoongArch. Try LZMA decompression. lzma_decompress_file: read on /tmp/Image4yyfhM of 65536 bytes failed pez_prepare: decompressed size 8563960 pez_prepare: done Cannot load vmlinuz.efi The root cause is that lzma decompressor requires more memory usage, which exceeds the current 64M limit. Reported-by: Huacai Chen <chenhuacai@kernel.org> Signed-off-by: WANG Rui <wangrui@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
2023-11-16kexec: ppc64: print help to stdout instead of stderrAditya Gupta3-15/+15
Currently 'kexec --help' on powerpc64 prints the generic help/usage to stdout, and the powerpc64 specific options to stderr That is, if the stdout of 'kexec --help' is redirected to some file, some of the help options will not be redirected, and instead printed on the terminal/stderr: [root@machine kexec-tools]# kexec --help > /tmp/out --command-line=<Command line> command line to append. --append=<Command line> same as --command-line. --ramdisk=<filename> Initial RAM disk. --initrd=<filename> same as --ramdisk. --devicetreeblob=<filename> Specify device tree blob file. Not applicable while using --kexec-file-syscall. --dtb=<filename> same as --devicetreeblob. elf support is still broken --elf64-core-headers Prepare core headers in ELF64 format --dt-no-old-root Do not reuse old kernel root= param. while creating flatten device tree. Fix this inconsistency by writing powerpc64 specific options to stdout, similar to the generic 'kexec --help' With the proposed changes, it is like this (nothing printed to stderr): [root@machine kexec-tools]# ./build/sbin/kexec --help > /tmp/out Reported-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Signed-off-by: Aditya Gupta <adityag@linux.ibm.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-10-11workflow: update to Ubuntu 22.04Simon Horman1-1/+1
Bump workflow to use latest LTS release. Signed-off-by: Simon Horman <horms@kernel.org>
2023-10-11kexec/loongarch64: fix 'make dist' file loss issueMing Wang1-0/+1
The Makefile omits the iomem.h file, causing the archive file generated by 'make dist' to lose iomem.h. This patch is used to fix this problem. Signed-off-by: Ming Wang <wangming01@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
2023-10-04kexec: provide a memfd_create() wrapper if not present in libcJulien Olivain2-0/+14
Commit 714fa115 "kexec/arm64: Simplify the code for zImage" introduced a use of the memfd_create() system call, included in version kexec-tools v2.0.27. This system call was introduced in kernel commit [1], first included in kernel v3.17 (released on 2014-10-05). The memfd_create() glibc wrapper function was added much later in commit [2], first included in glibc version 2.27 (released on 2018-02-01). This direct use memfd_create() introduced a requirement on Kernel >= 3.17 and glibc >= 2.27. There is old toolchains like [3] for example (which ships gcc 7.3.1, glibc 2.25 and includes kernel v4.10 headers), that can still be used to build newer kernels. Even if such toolchains can be seen as outdated, they are is still claimed as supported by recent kernel. For example, Kernel v6.5.5 has a requirement on gcc version 5.1 and greater. See [4]. Moreover, kexec-tools <= 2.0.26 could be compiled using recent toolchains with alternative libc (e.g. uclibc-ng, musl) which are not providing the memfd_create() wrapper. When compiling kexec-tools v2.0.27 with a toolchain not providing the memfd_create() syscall wrapper, the compilation fail with message: kexec/kexec.c: In function 'copybuf_memfd': kexec/kexec.c:645:7: warning: implicit declaration of function 'memfd_create'; did you mean 'SYS_memfd_create'? [-Wimplicit-function-declaration] fd = memfd_create("kernel", MFD_ALLOW_SEALING); ^~~~~~~~~~~~ SYS_memfd_create kexec/kexec.c:645:30: error: 'MFD_ALLOW_SEALING' undeclared (first use in this function); did you mean '_PC_ALLOC_SIZE_MIN'? fd = memfd_create("kernel", MFD_ALLOW_SEALING); ^~~~~~~~~~~~~~~~~ _PC_ALLOC_SIZE_MIN In order to let kexec-tools compile in a wider range of configurations, this commit adds a memfd_create() function check in autoconf configure script, and adds a system call wrapper which will be used if the function is not available. With this commit, the environment requirement is relaxed to only kernel >= v3.17. Note: this issue was found in kexec-tools integration in Buildroot [5] using the command "utils/test-pkg -a -p kexec", which tests many toolchain/arch combinations. [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9183df25fe7b194563db3fec6dc3202a5855839c [2] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=59d2cbb1fe4b8601d5cbd359c3806973eab6c62d [3] https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/aarch64-linux-gnu/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz [4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/process/changes.rst?h=v6.5.5#n32 [5] https://buildroot.org/ Signed-off-by: Julien Olivain <ju.o@free.fr> Signed-off-by: Simon Horman <horms@kernel.org>
2023-10-04crashdump/x86: set the elfcorehdr segment size for hotplugEric DeVolder1-0/+8
For hotplug, the elfcorehdr segment must be sized appropriately to allow a growing number of CPUs or memory regions. Use the size reported by the kernel via /sys/kernel/crash_elfcorehdr_sz. Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-10-04crashdump/x86: identify elfcorehdr segment for hotplugEric DeVolder1-0/+3
Identify the segment containing the elfcorehdr buffer so that it can be excluded from the purgatory checksum/digest, if hotplug support is in effect. Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-10-04crashdump: exclude elfcorehdr segment from digest for hotplugEric DeVolder2-0/+9
To allow direct modification of the elfcorehdr by the kernel, in response to CPU and memory hot un/plug and/or online/offline events, the buffer containing the elfcorehdr must be excluded from the purgatory checksum/digest. If the elfcorehdr is not excluded from the purgatory checksum/digest, then at panic time, the checksum/digest check fails (due to the elfcorehdr having been modified), and the kdump capture kernel does not start. Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-10-04crashdump: setup general hotplug supportEric DeVolder1-0/+18
To allow direct modification of the elfcorehdr by the kernel, in response to CPU and memory hot un/plug and/or online/offline events, the following conditions must occur: - the elfcorehdr buffer must be excluded from the purgatory checksum/digest, and - the elfcorehdr segment must be large enough, and - the kernel must be notified that it can modify the elfcorehdr Excluding the elfcorehdr buffer from the digest occurs in patch "crashdump: exclude elfcorehdr segment from digest for hotplug". If this is not done, a change to the elfcorehdr will cause the purgatory check at panic time to fail, and kdump capture kernel does not start. For hotplug, the size of the elfcorehdr segment is obtained from the kernel via the /sys/kernel/crash_elforehdr_size node. The KEXEC_UPDATE_ELFCOREHDR flag indicates to the kernel that it can make direct modifications to the elfcorehdr. Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-10-04crashdump: introduce the hotplug command line optionsEric DeVolder3-1/+18
Introducing the --hotplug command line option, which is used to indicate to the kernel that the kdump image is setup to permit the kernel to directly modify the elfcorehdr in response to CPU and memory hotplug and/or online/offline events. This option is only meaningful for kexec_load() syscall. For the kexec_file_load() syscall, this option is a no-op as the kernel handles all aspects of loading the kdump image. This is the command line processing and documentation. Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-10-04kexec: define KEXEC_UPDATE_ELFCOREHDREric DeVolder1-0/+1
The Linux kernel defines this flag to indicate that the kexec_load()'ed image is setup so that the kernel may directly modify the elfcorehdr (and not cause the purgatory digest checksum to fail) in response to CPU or memory hot un/plug and/or on/offline events. Define this flag to match/mirror the kernel flag. Signed-off-by: Eric DeVolder <eric.devolder@oracle.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-10-04kexec: update manpage with explicit mention of clean kexecHari Bathini1-2/+9
While the manpage does mention about kexec boot with a clean shutdown, it is not explicit about it. Make it explicit. Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-09-20zboot: add loongarch kexec_load supportDave Young5-0/+97
Copy arm64 code and change for loongarch so that the kexec -c can load a zboot image. Note: probe zboot image first otherwise the pei-loongarch file type will be used. Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-09-20zboot: enable arm64 kexec_load for zboot imageDave Young5-6/+30
kexec_file_load support of zboot kernel image decompressed the vmlinuz, so in kexec_load code just load the kernel with reading the decompressed kernel fd into a new buffer and use it directly. Signed-off-by: Dave Young <dyoung@redhat.com> Tested-by: Baoquan He <bhe@redhat.com> Reviewed-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-09-01build: fix tarball creationLeah Neukirchen1-4/+1
The fix in 41b77edac did not work, bsdtar still complains about "hardlink pointing to itself". Simplify the code instead: since the staging directory contains exactly the files we want, just package it as a whole. Signed-off-by: Leah Neukirchen <leah@vuxu.org> Signed-off-by: Simon Horman <horms@kernel.org>
2023-09-01kexec-tools 2.0.27.gitSimon Horman1-1/+1
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@kernel.org>
2023-08-28kexec-tools 2.0.27v2.0.27Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@kernel.org>
2023-08-18kexec-tools 2.0.27-rc1v2.0.27-rc1Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@kernel.org>
2023-08-11arm64: Hook up the ZBOOT support as vmlinuzJeremy Linton3-1/+9
Add the previously defined _probe() and _usage() routines to the kexec file types table, and build the new module. It should be noted that this "vmlinuz" support reuses the "Image" support to actually load the resulting image after it has been decompressed to a temporary file. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-08-11arm64: Add ZBOOT PE containing compressed image supportJeremy Linton2-0/+111
The kernel EFI stub ZBOOT feature creates a PE that contains a compressed linux kernel image. The stub when run in a valid UEFI environment then decompresses the resulting image and executes it. Support these image formats with kexec as well to avoid having to keep an alternate kernel image around. This patch adds a the _probe(), _load() and usage() routines needed for kexec to understand this format. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> [Modified by Pingfan to export kernel fd with load method] Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-08-11kexec/zboot: Add arch independent zboot supportJeremy Linton4-0/+148
The linux kernel CONFIG_ZBOOT option creates self decompressing PE kernel images. So this means that kexec should have a generic understanding of the format which may be used by multiple arches. So lets add an arch independent validation and decompression routine. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> [Modified by Pingfan to export kernel fd] Signed-off-by: Pingfan Liu <piliu@redhat.com> [Corrected indentation] Signed-off-by: Simon Horman <horms@kernel.org>
2023-08-11kexec: Introduce a member kernel_fd in kexec_infoPingfan Liu2-0/+9
Utilize the image load interface to export the kernel fd, which points to the uncompressed kernel and will be passed to kexec_file_load. The credit goes to the Dave Young, who contributes the original code. Signed-off-by: Pingfan Liu <piliu@redhat.com> Co-authored-by: Dave Young <dyoung@redhat.com> Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-08-11kexec/arm64: Simplify the code for zImagePingfan Liu6-254/+26
Inside zimage_probe(), it uncompresses the kernel and performs some check, similar to image_probe(). Taking a close look, the uncompressing has already executed before the image probe is called. What is missing here is to provide a fd, pointing to an uncompressed kernel image. This patch creates a memfd based on the result produced by slurp_decompress_file(), and finally simplify the logical of the probe for aarch64. The credit goes to the Dave Young, who contributes the original code. Signed-off-by: Pingfan Liu <piliu@redhat.com> Co-authored-by: Dave Young <dyoung@redhat.com> Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-03-08LoongArch: kdump: Set up kernel image segmentYouling Tang5-1/+40
On LoongArch, we can use the same kernel image as 1st kernel when 3f89765d622 ("LoongArch: kdump: Add single kernel image implementation") is merged, but we have to modify the entry point as well as segments addresses in the kernel elf header (or PE format vmlinux.efi) in order to load them into correct places. Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
2023-03-08kexec: __NR_kexec_file_load is set to undefined on LoongArchYouling Tang1-1/+1
The initial reason is that after the merger of 29fe5067ed07 ("kexec: make -a the default"), kexec cannot be used on LoongArch architectures. We need to add "-c" for normal use. The current kexec_file_load system call is not implemented in architectures such as LoongArch, so it needs to pass kexec_load. So we need to set __NR_kexec_file_load to undefined in unsupported architectures. This will return EFALLBACK via is_kexec_file_load_implemented, and then via kexec_load. Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
2023-03-03ppc64: Add elf-ppc64 file types/options and an arch specific flag to man pageGautam Menghani1-0/+35
Document the elf-ppc64 file options and the "--dt-no-old-root" arch specific flag in the man page. Signed-off-by: Gautam Menghani <gautam@linux.vnet.ibm.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-02-23x86: add devicetree supportJulian Winkler7-4/+43
Since linux kernel has dropped support for simple firmware interface (SFI), the only way of boot newer versions on intel MID platform is using devicetree Signed-off-by: Julian Winkler <julian.winkler1@web.de> Signed-off-by: Simon Horman <horms@kernel.org>
2023-02-07kexec: make -a the defaultAhelenia Ziemiańska2-6/+6
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>
2023-02-07ppc64: add --reuse-cmdline parameter supportSourabh Jain2-3/+26
An option to copy the command line arguments from running kernel to kexec'd kernel. This option works for both kexec and kdump. In case --append=<args> or --command-line=<args> is provided along with --reuse-cmdline parameter then args listed against append and command-line parameter will be combined with command line argument from running kernel. Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com> Signed-off-by: Simon Horman <horms@kernel.org>
2023-02-07kexec-tools 2.0.26.gitSimon Horman1-1/+1
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@kernel.org>
2022-12-21kexec-tools 2.0.26v2.0.26Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@kernel.org>
2022-12-07kexec-tools 2.0.26-rc1v2.0.26-rc1Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@kernel.org>
2022-11-18m68k: pass rng seed via BI_RNG_SEEDJason A. Donenfeld3-0/+34
In order to pass fresh entropy to kexec'd kernels, use BI_RNG_SEED for passing a seed, with the same semantics that kexec-tools currently uses for i386's setup_data. Link: https://git.kernel.org/torvalds/c/dc63a086daee92c63e3 Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Simon Horman <horms@kernel.org>
2022-10-28workflow: update to checkout@v3Simon Horman1-1/+1
Use to checkout@v3 instead of checkout@v2 as the latter uses Node.js 12 actions which are deprecated. https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/ Signed-off-by: Simon Horman <horms@kernel.org>
2022-10-10LoongArch: Remove redundant cmdline parameters when using --reuse-cmdline optionYouling Tang3-1/+4
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>
2022-10-10LoongArch: Add purgatory framework codeYouling Tang5-0/+31
Add purgatory framework code, no specific implementation, just consistent with other architectures. Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
2022-10-10LoongArch: PE format image loading supportYouling Tang6-0/+229
The LoongArch kernel will mainly use the vmlinux.efi image in PE format, so add it support. I tested this on LoongArch 3A5000 machine and works as expected, kexec: $ sudo kexec -l /boot/vmlinux.efi --reuse-cmdline $ sudo kexec -e kdump: $ sudo kexec -p /boot/vmlinux-kdump.efi --reuse-cmdline --append="nr_cpus=1" # echo c > /proc/sysrq_trigger Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
2022-10-10LoongArch: Add kexec/kdump supportYouling Tang14-0/+854
Add the 64-bit processing support of the LoongArch architecture. For the time being, the quick restart function(kexec) is supported. That is, the "kexec -l" and "kexec -e" commands can be used normally. At the same time, the crash dump function also supports, "kexec -p" operation can be successfully performed, and the vmcore file can be generated. I tested this on LoongArch 3A5000 machine and works as expected, kexec: $ sudo kexec -l /boot/vmlinux --reuse-cmdline $ sudo kexec -e kdump: $ sudo kexec -p /boot/vmlinux-kdump --reuse-cmdline --append="nr_cpus=1" # echo c > /proc/sysrq_trigger Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
2022-10-10config: Add LoongArch architecture support in config.guess and config.sub filesYouling Tang2-0/+4
Add configuration files required by LoongArch architecture, including config.guess and config.sub files. The source file comes from: https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess and https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
2022-10-05ppc64: remove rma_top limitSourabh Jain1-2/+0
Restricting kexec tool to allocate hole for kexec segments below 768MB may not be relavent now since first memory block size can be 1024MB and more. Removing rma_top restriction will give more space to find holes for kexec segments and existing in-place checks make sure that kexec segment allocation doesn't cross the first memory block because every kexec segment has to be within first memory block for kdump kernel to boot properly. Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com> Acked-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Simon Horman <horms@kernel.org>
2022-07-31kexec-tools 2.0.25.gitSimon Horman1-1/+1
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@kernel.org>
2022-07-31kexec-tools 2.0.25v2.0.25Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@kernel.org>
2022-07-19kexec-tools 2.0.25-rc1v2.0.25-rc1Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@kernel.org>
2022-07-19kexec-tools: Remove duplicate ultoa() definitions and redefine itTiezhu Yang6-95/+16
There exist duplicate ultoa() definitions in many archs, remove them, and also redefine ultoa() in kexec/kexec.h to make it more readable. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
2022-07-15i386: pass rng seed via setup_dataJason A. Donenfeld1-0/+25
Linux ≥5.20 expects a RNG seed via setup_data as of the upstream commit in the link below. That commit adjusts kexec_file_load to pass SETUP_RNG_SEED. kexec-tools should follow suite, so add more or less the same code here. Link: https://git.kernel.org/tip/tip/c/68b8e9713c8 Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Simon Horman <horms@kernel.org>
2022-06-26kexec-tools: mips: Pass initrd parameter via cmdlineHui Li3-3/+80
Under loongson platform, use command: kexec -l vmlinux... --append="root=UUID=28e1..." --initrd=... kexec -e quick restart failed like this: ******************************************************************** [ 3.420791] VFS: Cannot open root device "UUID=6462a8a4-02fb-49..." [ 3.431262] Please append a correct "root=" boot option; ... ... ... ... [ 3.543175] 0801 4194304 sda1 554e69cc-01 [ 3.543175] [ 3.549494] 0802 62914560 sda2 554e69cc-02 [ 3.549495] [ 3.555818] 0803 8388608 sda3 554e69cc-03 [ 3.555819] [ 3.562139] 0804 174553229 sda4 554e69cc-04 [ 3.562139] [ 3.568463] 0b00 1048575 sr0 [ 3.568464] driver: sr [ 3.574524] Kernel panic - not syncing: VFS: Unable to mount root fs... [ 3.582750] ---[ end Kernel panic - not syncing: VFS:... ******************************************************************* The kernel cannot parse the UUID, the UUID is parsed in the initrd. For compatibility with previous platforms, loongson platform obtain initrd parameter through cmdline in kernel, the kernel supports use cmdline to parse initrd. But under the mips architecture, kexec-tools pass the initrd through DTB. Made the following modifications: (1) in kexec/arch/mips/kexec-elf-mips.c Add patch_initrd_info(), at runtime to distinguish different cpu, only for loongson cpu, add initrd parameter to cmdline. (2) in kexec/arch/mips/crashdump-mips.c Because loongson uses a different page_offset, it should be modified to ensure that crashdump functionality is correct and reliable. (3) in kexec/arch/mips/crashdump-mips.h Added platform-specific page_offset macro definition. Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Simon Horman <horms@kernel.org>
2022-04-29arm64/crashdump-arm64: increase CRASH_MAX_MEMORY_RANGES to 32kabuehaze141-1/+1
On ARM64 based VMs hotplugging more than 31GB of memory will cause kdump to fail loading as it's hitting the CRASH_MAX_MEMORY_RANGES limit which is currently 32 on ARM64 given that the memory block size is 1GB. This patch is raising CRASH_MAX_MEMORY_RANGES to 32K similar to what we have on x86, this should allow kdump to work until the VM has 32TB which should be enough for a long time. Signed-off-by: Hazem Mohamed Abuelfotoh <abuehaze@amazon.com> Acked-by: Baoquan He <bhe@redhat.com> Signed-off-by: Simon Horman <horms@kernel.org>
2022-04-29kexec-tools 2.0.23.gitSimon Horman1-1/+1
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@kernel.org>
2022-04-09kexec-tools 2.0.24v2.0.24Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-01kexec-tools 2.0.24-rc1v2.0.24-rc1Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-01arm64: fix static data relocations in machine_apply_elf_rel()Pingfan Liu1-3/+2
As for 'static data relocations', instead of patching an instruction (OR ops), it should be assigned to value directly. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-01kexec/elf: assign one to align if sh_addralign equals zeroPingfan Liu1-3/+7
According to ELF specification, if sh_addralign equals zero or one, then the section has no alignment requirement on the start address. (I.e. it can be aligned on 1 byte) Since modern cpu asks the .text, .data, .bss to be aligned on the machine word boundary at least, so in elf_rel_load(), sh_addralign can not be zero, and align = shdr->sh_addralign; ... bufsz = _ALIGN(bufsz, align); will not render a result of 'bufsz = 0'. But it had better have a check on the case of 'sh_addralign == 0' regardless of the assumption of machine word alignment. This patch has no functional change. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-01arm64/crashdump-arm64: explicit type conversion to suppress compiler warningPingfan Liu1-1/+1
elf_info.page_offset is 'unsigned long long', while get_page_offset() has the input param as a type of 'unsigned long *'. It demands explicit type casting to mute the compiler warning. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-01arm64/kexec-arm64: add support for R_AARCH64_MOVW_UABS_G* relaPingfan Liu1-0/+40
Build kexec-tools with clang(clang version 13.0.1 (Fedora 13.0.1-1.fc36)). Then when kexec loads kernel, it runs into the error message "machine_apply_elf_rel: ERROR Unknown type: 264". This is caused by the following reloc type in purgatory/purgatory.ro, which is not supported yet. R_AARCH64_MOVW_UABS_G0_NC R_AARCH64_MOVW_UABS_G1_NC R_AARCH64_MOVW_UABS_G2_NC R_AARCH64_MOVW_UABS_G3 Adding code to support these relocs, so kexec can work smoothly. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-01arm64/kexec-arm64: use enum to organize the reloc typePingfan Liu1-41/+15
More and more reloc type need to be supported on aarch64. Using enum to organize them to shorten the #ifdef macro list. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-04-01arm64/kexec-arm64: add support for R_AARCH64_LDST128_ABS_LO12_NC relaPingfan Liu1-0/+16
GCC 12 has some changes, which affects the generated AArch64 code of kexec-tools. Accordingly, a new rel type R_AARCH64_LDST128_ABS_LO12_NC is confronted by machine_apply_elf_rel() on AArch64. This fails the load of kernel with the message "machine_apply_elf_rel: ERROR Unknown type: 299" Citing from objdump -rDSl purgatory/purgatory.ro 0000000000000f80 <sha256_starts>: sha256_starts(): f80: 90000001 adrp x1, 0 <verify_sha256_digest> f80: R_AARCH64_ADR_PREL_PG_HI21 .text+0xfa0 f84: a9007c1f stp xzr, xzr, [x0] f88: 3dc00021 ldr q1, [x1] f88: R_AARCH64_LDST128_ABS_LO12_NC .text+0xfa0 f8c: 90000001 adrp x1, 0 <verify_sha256_digest> f8c: R_AARCH64_ADR_PREL_PG_HI21 .text+0xfb0 f90: 3dc00020 ldr q0, [x1] f90: R_AARCH64_LDST128_ABS_LO12_NC .text+0xfb0 f94: ad008001 stp q1, q0, [x0, #16] f98: d65f03c0 ret f9c: d503201f nop fa0: 6a09e667 .inst 0x6a09e667 ; undefined fa4: bb67ae85 .inst 0xbb67ae85 ; undefined fa8: 3c6ef372 .inst 0x3c6ef372 ; undefined fac: a54ff53a ld3w {z26.s-z28.s}, p5/z, [x9, #-3, mul vl] fb0: 510e527f sub wsp, w19, #0x394 fb4: 9b05688c madd x12, x4, x5, x26 fb8: 1f83d9ab .inst 0x1f83d9ab ; undefined fbc: 5be0cd19 .inst 0x5be0cd19 ; undefined Here, gcc generates codes, which make loads and stores carried out using the 128-bits floating-point registers. And a new rel type R_AARCH64_LDST128_ABS_LO12_NC should be handled. Make machine_apply_elf_rel() coped with this new reloc, so kexec-tools can work smoothly. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-03-30kexec-tools: fix leak FILE pointer.Lichen Liu1-1/+4
Close fp if file size is smaller than 13 bytes. Fixes: dcfcc73c73e6 ("kexec-tools: Determine if the image is lzma commpressed") Signed-off-by: Lichen Liu <lichliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-03-30purgatory: do not enable vectorization automatically for purgatory compilingBaoquan He1-1/+1
Redhat CKI reported kdump kernel will hang a while very early after crash triggered, then reset to firmware to reboot. This failure can only be observed with kdump or kexec reboot via kexec_load system call. With kexec_file_load interface, both kdump and kexec reboot work very well. And further investigation shows that gcc version 11 doesn't have this issue, while gcc version 12 does. After checking the release notes of the latest gcc, Dave found out it's because gcc 12 enables auto-vectorization for -O2 optimization level. Please see below link for more information: https://www.phoronix.com/scan.php?page=news_item&px=GCC-12-Auto-Vec-O2 Adding -fno-tree-vectorize to Makefile of purgatory can fix the issue. Signed-off-by: Baoquan He <bhe@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-03-29kexec-tools: Determine if the image is lzma commpressedLichen Liu1-0/+36
Currently there are 2 functions for decompressing compressed image. The zlib_decompress_file() will determine if the image is compressed by gzip before read, but lzma_decompress_file() will not. This can cause misleading information to be printed when the image is not compressed by lzma and debug option is used: ]# kexec -d -s -l /boot/vmlinuz-5.14.10-300.fc35.x86_64 \ --initrd /boot/initramfs-5.14.10-300.fc35.x86_64.img \ --reuse-cmdline Try gzip decompression. Try LZMA decompression. lzma_decompress_file: read on /boot/vmlinuz-5.14.10-300.fc35.x86_64 of 65536 bytes failed Add a helper function is_lzma_file() to help behave consistently. Signed-off-by: Lichen Liu <lichliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-03-24util_lib/elf_info: harden parsing of printk bufferPhilipp Rudo1-3/+25
The old printk mechanism (> v3.5.0 and < v5.10.0) had a fixed size buffer (log_buf) that contains all messages. The location for the next message is stored in log_next_idx. In case the log_buf runs full log_next_idx wraps around and starts overwriting old messages at the beginning of the buffer. The wraparound is denoted by a message with msg->len == 0. Following the behavior described above blindly is dangerous as e.g. a memory corruption could overwrite (parts of) the log_buf. If the corruption adds a message with msg->len == 0 this leads to an endless loop when dumping the dmesg. Fix this by verifying that not wrapped around before when it encounters a message with msg->len == 0. While at it also verify that the index is within the log_buf and thus guard against corruptions with msg->len != 0. The same bug has been reported and fixed in makedumpfile [1]. [1] http://lists.infradead.org/pipermail/kexec/2022-March/024272.html Signed-off-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-03-24github: run apt-get update before installing packagesSimon Horman1-1/+3
Refresh package database before installing dependencies to avoid failures due to trying to install older, no longer available, versions of packages. Signed-off-by: Simon Horman <horms@verge.net.au>
2022-03-23kexec-xen: Allow xen_kexec_exec() to return in case of Live UpdateRaphael Ning3-9/+28
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>
2022-03-23kexec-tools: print error if kexec_file_load failsHari Bathini1-0/+1
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>
2022-02-01kexec-tools: mips: Concatenate --reuse-cmdline and --appendTiezhu Yang1-2/+6
Use concat_cmdline() to concatenate the --append string and the --reuse-cmdline string, otherwise only one of the two options is valid. This is similar with commit 8b42c99aa3bc ("Fix --reuse-cmdline so it is usable."). Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-02-01kexec-tools: mips: Add some debug infoTiezhu Yang1-0/+7
Use dbgprintf() to print command_line, initrd and dtb in arch_process_options() for debugging. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-24arm64: fix PAGE_OFFSET calc for flipped mmKairui Song1-1/+13
Since kernel commit 14c127c957c1 ('arm64: mm: Flip kernel VA space'), the memory layout on arm64 have changed, and kexec-tools can no longer get the the right PAGE_OFFSET based on _text symbol. Prior to that, the kimage (_text) lays above PAGE_END with this layout: 0 -> VA_START : Usespace VA_START -> VA_START + 256M : BPF JIT, Modules VA_START + 256M -> PAGE_OFFSET - (~GB misc) : Vmalloc (KERNEL _text HERE) PAGE_OFFSET -> ... : * Linear map * And here we have: VA_START = -1UL << VA_BITS PAGE_OFFSET = -1UL << (VA_BITS - 1) _text < -1UL << (VA_BITS - 1) Kernel image lays somewhere between VA_START and PAGE_OFFSET, so we just calc VA_BITS by getting the highest unset bit of _text symbol address, and shift one less bit of VA_BITS to get page offset. This works as long as KASLR don't put kernel in a too high location (which is commented inline). And after that commit, kernel layout have changed: 0 -> PAGE_OFFSET : Userspace PAGE_OFFSET -> PAGE_END : * Linear map * PAGE_END -> PAGE_END + 128M : bpf jit region PAGE_END + 128M -> PAGE_END + 256MB : modules PAGE_END + 256M -> ... : vmalloc (KERNEL _text HERE) Here we have: PAGE_OFFSET = -1UL << VA_BITS PAGE_END = -1UL << (VA_BITS - 1) _text > -1UL << (VA_BITS - 1) Kernel image now lays above PAGE_END, so we have to shift one more bit to get the VA_BITS, and shift the exact VA_BITS for PAGE_OFFSET. We can simply check if "_text > -1UL << (VA_BITS - 1)" is true to judge which layout is being used and shift the page offset occordingly. Signed-off-by: Kairui Song <kasong@tencent.com> (rebased and stripped by Pingfan ) Signed-off-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-24arm64: read VA_BITS from kcore for 52-bits VA kernelPingfan Liu3-4/+36
phys_to_virt() calculates virtual address. As a important factor, page_offset is excepted to be accurate. Since arm64 kernel exposes va_bits through vmcore, using it. Signed-off-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-24arm64/crashdump: unify routine to get page_offsetPingfan Liu3-26/+6
There are two funcs to get page_offset: get_kernel_page_offset() get_page_offset() Since get_kernel_page_offset() does not observe the kernel formula, and remove it. Unify them in order to introduce 52-bits VA kernel more easily in the coming patch. Signed-off-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-24arm64: make phys_offset signedPingfan Liu4-9/+9
After kernel commit 7bc1a0f9e176 ("arm64: mm: use single quantity to represent the PA to VA translation"), phys_offset can be negative if running 52-bits kernel on 48-bits hardware. So changing phys_offset from unsigned to signed. Signed-off-by: Pingfan Liu <piliu@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-14s390: add support for --reuse-cmdlineSven Schnelle2-4/+15
--reuse-cmdline reads the command line of the currently running kernel from /proc/cmdline and uses that for the kernel that should be kexec'd. Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-14use slurp_proc_file() in get_command_line()Sven Schnelle1-16/+10
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>
2022-01-14add slurp_proc_file()Sven Schnelle1-0/+51
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>
2022-01-14s390: use KEXEC_ALL_OPTIONSSven Schnelle1-8/+2
KEXEC_ALL_OPTIONS could be used instead defining the same array several times. This makes code easier to maintain when new options are added. Suggested-by: Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-14s390: add variable command line sizeSven Schnelle3-34/+55
Newer s390 kernels support a command line size longer than 896 bytes. Such kernels contain a new member in the parameter area, which might be utilized by tools like kexec. Older kernels have the location initialized to zero, so we check whether there's a non-zero number present and use that. If there isn't, we fallback to the legacy command line size of 896 bytes. Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-14arm64: support more than one crash kernel regionsChen Zhou3-47/+86
When crashkernel is reserved above 4G in memory, kernel should reserve some amount of low memory for swiotlb and some DMA buffers. So there may be two crash kernel regions, one is below 4G, the other is above 4G. Currently, there is only one crash kernel region on arm64, and pass "linux,usable-memory-range = <BASE SIZE>" property to crash dump kernel. Now, we pass "linux,usable-memory-range = <BASE1 SIZE1 BASE2 SIZE2>" to crash dump kernel to support two crash kernel regions and load crash kernel high. Make the low memory region as the second range "BASE2 SIZE2" to keep compatibility with existing user-space and older kdump kernels. Signed-off-by: Chen Zhou <chenzhou10@huawei.com> Co-developed-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2022-01-14s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()Alexander Egorenkov1-1/+2
Starting with gcc 11.3, the C compiler will generate PLT-relative function calls even if they are local and do not require it. Later on during linking, the linker will replace all PLT-relative calls to local functions with PC-relative ones. Unfortunately, the purgatory code of kexec/kdump is not being linked as a regular executable or shared library would have been, and therefore, all PLT-relative addresses remain in the generated purgatory object code unresolved. This in turn lets kexec-tools fail with "Unknown rela relocation: 0x14 0x73c0901c" for such relocation types. Furthermore, the clang C compiler has always behaved like described above and this commit should fix the purgatory code built with the latter. Because the purgatory code is no regular executable or shared library, contains only calls to local functions and has no PLT, all R_390_PLT32DBL relocation entries can be resolved just like a R_390_PC32DBL one. * https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries/x1633.html#AEN1699 Relocation entries of purgatory code generated with gcc 11.3 ------------------------------------------------------------ $ readelf -r purgatory/purgatory.o Relocation section '.rela.text' at offset 0x6e8 contains 27 entries: Offset Info Type Sym. Value Sym. Name + Addend 00000000000c 000300000013 R_390_PC32DBL 0000000000000000 .data + 2 00000000001a 001000000014 R_390_PLT32DBL 0000000000000000 sha256_starts + 2 000000000030 001100000014 R_390_PLT32DBL 0000000000000000 sha256_update + 2 000000000046 001200000014 R_390_PLT32DBL 0000000000000000 sha256_finish + 2 000000000050 000300000013 R_390_PC32DBL 0000000000000000 .data + 102 00000000005a 001300000014 R_390_PLT32DBL 0000000000000000 memcmp + 2 ... 000000000118 001600000014 R_390_PLT32DBL 0000000000000000 setup_arch + 2 00000000011e 000300000013 R_390_PC32DBL 0000000000000000 .data + 2 00000000012c 000f00000014 R_390_PLT32DBL 0000000000000000 verify_sha256_digest + 2 000000000142 001700000014 R_390_PLT32DBL 0000000000000000 post_verification[...] + 2 Relocation entries of purgatory code generated with gcc 11.2 ------------------------------------------------------------ $ readelf -r purgatory/purgatory.o Relocation section '.rela.text' at offset 0x6e8 contains 27 entries: Offset Info Type Sym. Value Sym. Name + Addend 00000000000e 000300000013 R_390_PC32DBL 0000000000000000 .data + 2 00000000001c 001000000013 R_390_PC32DBL 0000000000000000 sha256_starts + 2 000000000036 001100000013 R_390_PC32DBL 0000000000000000 sha256_update + 2 000000000048 001200000013 R_390_PC32DBL 0000000000000000 sha256_finish + 2 000000000052 000300000013 R_390_PC32DBL 0000000000000000 .data + 102 00000000005c 001300000013 R_390_PC32DBL 0000000000000000 memcmp + 2 ... 00000000011a 001600000013 R_390_PC32DBL 0000000000000000 setup_arch + 2 000000000120 000300000013 R_390_PC32DBL 0000000000000000 .data + 122 000000000130 000f00000013 R_390_PC32DBL 0000000000000000 verify_sha256_digest + 2 000000000146 001700000013 R_390_PC32DBL 0000000000000000 post_verification[...] + 2 Corresponding s390 kernel discussion: * https://lore.kernel.org/linux-s390/20211208105801.188140-1-egorenar@linux.ibm.com/T/#u Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com> Reported-by: Tao Liu <ltao@redhat.com> Suggested-by: Philipp Rudo <prudo@redhat.com> Reviewed-by: Philipp Rudo <prudo@redhat.com> [hca@linux.ibm.com: changed commit message as requested by Philipp Rudo] Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-12-15arm64/crashdump: deduce paddr of _text based on kernel code sizePingfan Liu1-3/+11
kexec-tools commit 61b8c79b0fb7 ("arm64/crashdump-arm64: deduce the paddr of _text") tries to deduce the paddr of _text, but turns out partially. That commit is based on "The Image must be placed text_offset bytes from a 2MB aligned base address anywhere in usable system RAM and called there" in linux/Documentation/arm64/booting.rst, plus text_offset field is zero. But in practice, some boot loaders does not obey the convention, and still boots up the kernel successfully. Revisiting kernel commit e2a073dde921 ("arm64: omit [_text, _stext) from permanent kernel mapping"), the kernel code size changes from (unsigned long)__init_begin - (unsigned long)_text to (unsigned long)__init_begin - (unsigned long)_stext And it should be a better factor to decide which label starts the "Kernel code" in /proc/iomem. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-12-15kexec-tools 2.0.23.gitSimon Horman1-1/+1
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>
2021-11-04kexec-tools 2.0.23v2.0.23Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@verge.net.au>
2021-10-28kexec-tools 2.0.23-rc1v2.0.23-rc1Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@verge.net.au>
2021-10-20arm: kdump: Add DT properties to crash dump kernel's DTBGeert Uytterhoeven3-2/+147
Pass the following properties to the crash dump kernel, to provide a modern DT interface between kexec and the crash dump kernel: - linux,elfcorehdr: ELF core header segment, similar to the "elfcorehdr=" kernel parameter. - linux,usable-memory-range: Usable memory reserved for the crash dump kernel. This makes the memory reservation explicit, so Linux no longer needs to mask the program counter, and rely on the "mem=" kernel parameter to obtain the start and size of usable memory. For backwards compatibility, the "elfcorehdr=" and "mem=" kernel parameters are still appended to the kernel command line. Loosely based on the ARM64 version by Akashi Takahiro. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-10-20kexec-tools: multiboot2: Correct BASIC_MEMINFO memory unitsTu Dinh1-2/+2
mem_lower and mem_upper are measured in kilobytes. Signed-off-by: Simon Horman <horms@verge.net.au>
2021-10-05Add some necessary free() callsKai Song2-3/+11
free should be called before the function exit abnormally. Signed-off-by: Kai Song <songkai01@inspur.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-10-05Add some necessary fclose() callsKai Song4-1/+8
fclose should be called before function exits Signed-off-by: Kai Song <songkai01@inspur.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-09-24ppc64: Fix memory leak problem in zImage_ppc64_load()Kai Song1-0/+7
When the function exits abnormally,ph should be freed. Signed-off-by: Kai Song <songkai01@inspur.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-09-24i386: Remove unused local variable in get_kernel_page_offset()Kai Song1-1/+0
In get_kernel_page_offset(),the local variable kv is unused,remove it. Signed-off-by: Kai Song <songkai01@inspur.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-09-14multiboot2: Accept x86-64 imagesZhaofeng Li2-4/+6
Signed-off-by: Zhaofeng Li <hello@zhaofeng.li> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-09-14multiboot2: Avoid first 0x500 bytesZhaofeng Li1-1/+1
In some cases, add_buffer will actually try to allocate the buffer at 0x0, which may not be acceptable by some kernels. Let's avoid the first 0x500 bytes so we don't screw up the IVT and BDA. Signed-off-by: Zhaofeng Li <hello@zhaofeng.li> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-09-14multiboot2: Use rel_min and rel_max for buffer destinationsZhaofeng Li1-2/+2
This would segfault if mhi.rel_tag didn't exist. Signed-off-by: Zhaofeng Li <hello@zhaofeng.li> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-09-14multiboot2: Correct MBI size calculationZhaofeng Li1-4/+13
tag_load_base_addr is dependent on rel_tag, and tag_framebuffer was not accounted for. Signed-off-by: Zhaofeng Li <hello@zhaofeng.li> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-09-14x86: Consolidate elf_x86_probe routinesZhaofeng Li3-33/+40
Signed-off-by: Zhaofeng Li <hello@zhaofeng.li> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-09-13Refer FDT tokens with symbolic namesSourabh Jain1-10/+11
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>
2021-06-06arm64/crashdump-arm64: deduce the paddr of _textPingfan Liu1-2/+10
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>
2021-05-02kexec-tools: Remove duplicate definition of ramdiskPetr Tesarik1-1/+0
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>
2021-05-02kexec-tools 2.0.21.gitSimon Horman1-1/+1
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>
2021-05-02kexec-tools 2.0.22v2.0.22Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-26kexec-tools 2.0.22-rc1v2.0.22-rc1Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-17arm: do not copy magic 4 bytes of appended DTB in zImageAlexander Egorenkov1-1/+11
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>
2021-04-17kexec: Remove the error prone kernel_version functionEric W. Biederman6-85/+11
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>
2021-04-07Shrink segments to fit alignment instead of throwing them awayHongyan Xia1-3/+12
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>
2021-04-07Fix where the real mode interrupt vector endsHongyan Xia1-2/+8
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>
2021-04-02github: initial workflowSimon Horman1-0/+72
Initial github workflow which builds kexec on a range of architectures. Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-02build: add distcheck targetSimon Horman2-1/+39
Add distcheck target which aims to exercise build, install and uninstall using distribution tarball. Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-02build: simplify uninstall targetSimon Horman1-64/+17
This appears to have been copied from some generated code. Simplify it by rolling repetitive operations into a for loop. Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-02build: use DESTDIR in uninstall targetSimon Horman1-21/+21
For symmetry with the install target, also use DESTDIR in the uninstall target. Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-02build: uninstall kexec_testSimon Horman1-1/+5
kexec_test is installed but not uninstalled. Correct this oversight. Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-02build: add dist make targetSimon Horman1-1/+3
This provides a familiar alias for the existing tarball target. The result is a tar.gz file. Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-02build: create tarball without self-referential hard linksSimon Horman1-6/+5
The current method of creating the tarball, which is to the hard-link the source directory to the target directory, results in self-referential hardlinks which can be observed using tar xf. This patch resolves this by using an intermediate tarball, held in memory, which collects files to be distributed. This is then unpacked in the target directory which is finally packed into the distribution tarball, a file. Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-02crashdump/x86: increase CRASH_MAX_MEMORY_RANGES to 32kDavid Hildenbrand2-3/+6
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>
2021-04-02crashdump/x86: iterate only over actual crash memory rangesDavid Hildenbrand1-1/+1
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>
2021-04-02crashdump/x86: dump any kind of "System RAM"David Hildenbrand1-2/+8
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>
2021-04-02kexec-xen: Use correct image type for Live UpdateRaphael Ning1-9/+14
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>
2021-04-02kexec: Make --status work with normal kexec imagesRaphael Ning1-1/+3
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>
2021-04-02kexec: Fix description of --status exit codeRaphael Ning2-4/+5
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>
2021-04-02printk: Use %zu to format size_tGeert Uytterhoeven1-2/+2
When compiling for 32-bit: util_lib/elf_info.c: In function ‘dump_dmesg_lockless’: util_lib/elf_info.c:1095:39: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=] 1095 | fprintf(stderr, "Failed to malloc %lu bytes for prb: %s\n", | ~~^ | | | long unsigned int | %u 1096 | printk_ringbuffer_sz, strerror(errno)); | ~~~~~~~~~~~~~~~~~~~~ | | | size_t {aka unsigned int} util_lib/elf_info.c:1101:49: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=] 1101 | fprintf(stderr, "Failed to read prb of size %lu bytes: %s\n", | ~~^ | | | long unsigned int | %u 1102 | printk_ringbuffer_sz, strerror(errno)); | ~~~~~~~~~~~~~~~~~~~~ | | | size_t {aka unsigned int} Indeed, "size_t" is "unsigned int" on 32-bit platforms, and "unsigned long" on 64-bit platforms. Fix this by formatting using "%zu". Fixes: 4149df9005f2cdd2 ("printk: add support for lockless ringbuffer") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: John Ogness <john.ogness@linutronix.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-02printk: Use ULL suffix for 64-bit constantsGeert Uytterhoeven1-2/+2
When compiling for 32-bit: util_lib/elf_info.c: In function ‘get_desc_state’: util_lib/elf_info.c:923:31: warning: left shift count >= width of type [-Wshift-count-overflow] 923 | #define DESC_FLAGS_MASK (3UL << DESC_FLAGS_SHIFT) | ^~ util_lib/elf_info.c:925:25: note: in expansion of macro ‘DESC_FLAGS_MASK’ 925 | #define DESC_ID_MASK (~DESC_FLAGS_MASK) | ^~~~~~~~~~~~~~~ util_lib/elf_info.c:926:30: note: in expansion of macro ‘DESC_ID_MASK’ 926 | #define DESC_ID(sv) ((sv) & DESC_ID_MASK) | ^~~~~~~~~~~~ util_lib/elf_info.c:947:12: note: in expansion of macro ‘DESC_ID’ 947 | if (id != DESC_ID(state_val)) | ^~~~~~~ util_lib/elf_info.c: In function ‘id_inc’: util_lib/elf_info.c:923:31: warning: left shift count >= width of type [-Wshift-count-overflow] 923 | #define DESC_FLAGS_MASK (3UL << DESC_FLAGS_SHIFT) | ^~ util_lib/elf_info.c:925:25: note: in expansion of macro ‘DESC_FLAGS_MASK’ 925 | #define DESC_ID_MASK (~DESC_FLAGS_MASK) | ^~~~~~~~~~~~~~~ util_lib/elf_info.c:981:15: note: in expansion of macro ‘DESC_ID_MASK’ 981 | return (id & DESC_ID_MASK); | ^~~~~~~~~~~~ Indeed, "unsigned long" constants are 32-bit on 32-bit platforms, and 64-bit on 64-bit platforms. Fix this by using a "ULL" suffix instead. Fixes: 4149df9005f2cdd2 ("printk: add support for lockless ringbuffer") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: John Ogness <john.ogness@linutronix.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-02kexec: Use %llu/%llx and casts to format uint64_tGeert Uytterhoeven1-1/+2
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>
2021-04-02mips: Fix the increased mem parameter sizeYouling Tang1-1/+1
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>
2021-04-02i386: fix build on pre 4.4 kernelsFederico Pellegrin1-0/+4
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>
2021-04-02mips: Fix typo in commentYouling Tang1-1/+1
Fix typo in comment. Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Simon Horman <horms@verge.net.au>
2021-04-02mips: Add '--reuse-cmdline' optional parameter supportYouling Tang2-5/+11
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>
2020-12-17kexec-tools 2.0.21.gitSimon Horman1-1/+1
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>
2020-12-17kexec-tools 2.0.21v2.0.21Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@verge.net.au>
2020-12-09kexec-tools 2.0.21-rc1v2.0.21-rc1Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@verge.net.au>
2020-12-09kexec: mips: Fix mem parametersJinyang He1-0/+29
"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>
2020-12-09dt-ops: fix memory leak when new_node malloc failsqiuguorui11-1/+2
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>
2020-11-30zlib: fix resource leak when gzdirect failedqiuguorui11-2/+2
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>
2020-11-30printk: add support for lockless ringbufferJohn Ogness1-1/+437
Linux 5.10 moved to a new lockless ringbuffer. The new ringbuffer is structured completely different to the previous iterations. Add support for retrieving the ringbuffer using vmcoreinfo. The new ringbuffer is detected based on the availability of the "prb" symbol. Signed-off-by: John Ogness <john.ogness@linutronix.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-11-16x86_64: allow ELFCLASS32 for x32 supportAhelenia Ziemiańska1-1/+2
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-11-16i386: fix string formatting-related warningsAhelenia Ziemiańska1-2/+14
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>
2020-11-16i386/kexec-mb2-x86.c: cast ints to uintptr_t before pointers to avoid warningsAhelenia Ziemiańska1-3/+3
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-11-16configure.ac, arch/x86_64: handle x32 as subarch of x86_64 and don't specify ↵Ahelenia Ziemiańska2-0/+13
-mcmodel=large there Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-11-16config: update to latest config.{sub,guess}, install-shAhelenia Ziemiańska3-1924/+2128
Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-10-23arm64: Add purgatory printingMatthias Brugger3-2/+92
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 Sharma2-6/+32
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 Sharma1-4/+4
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 Tang3-8/+27
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 Tang1-1/+1
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 Tang1-29/+0
"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 Tang1-0/+3
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 Aziz1-1/+1
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 Tang1-1/+1
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 He1-0/+3
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 He1-7/+8
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 Stelmach1-7/+8
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 Bathini1-0/+1
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 Stelmach4-6/+6
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 Tesarik1-0/+1
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 Gautam3-7/+22
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 Gautam5-10/+125
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 Gautam3-33/+41
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 Song4-7/+4
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. Barbosa1-12/+0
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 Jiang1-1/+1
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 Tesarik1-2/+10
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 Tesarik2-54/+61
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 Cascardo1-2/+2
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 Packham2-1/+6
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 Maier1-1/+1
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 Takahiro1-15/+10
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 Takahiro1-59/+94
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 Takahiro2-0/+49
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 Deller1-1/+1
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 Deller1-1/+2
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 Schnelle9-0/+406
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 Wang1-0/+4
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 Sharma1-2/+0
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 Sharma1-1/+1
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 Jiang1-0/+10
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 Jiang3-39/+41
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 Jiang2-2/+2
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 Jiang3-15/+4
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 Buczek2-1/+4
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 Horman1-1/+1
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.20v2.0.20Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-16kexec-tools 2.0.20-rc2v2.0.20-rc2Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-16kexec/arm64: Add support for handling zlib compressed (Image.gz) imageBhupesh Sharma6-3/+250
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 Sharma2-0/+39
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 Sharma1-1/+12
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 Sharma1-0/+2
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-rc1v2.0.20-rc1Simon Horman1-1/+1
Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-10x86: Include kexec-mb2-x86.c and multiboot2.h in distributionSimon Horman2-1/+4
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 Horman1-1/+1
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>
2019-07-03x86: Support multiboot2 imagesVarad Gautam7-0/+993
Add a new type `multiboot2-x86` that allows loading multiboot2 [1] images within the relocation range specified in the image header. The image is always placed at the lowest available address, regardless of the preference information. [1] https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html Signed-off-by: Varad Gautam <vrd@amazon.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-07-03elf: Support ELF loading with relocationVarad Gautam2-65/+141
Add a helper to allow loading an image within specified address range. This will be used to load multiboot2 images later. Signed-off-by: Varad Gautam <vrd@amazon.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-31crashdump/x86: Use new introduce helper for getting RSDPKairui Song1-25/+9
Use the new introduce helper for getting RSDP, this ensures RSDP is always accessible and avoid code duplication. Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-31x86: Always try to fill acpi_rsdp_addr in boot paramsKairui Song1-0/+3
Since kernel commit e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP address from boot params if available"), kernel accept an acpi_rsdp_addr param in boot_params. So fill in this parameter unconditionally, ensure second kernel always get the right RSDP address consistently, and boot well on EFI system even with EFI service disabled. User no longer need to change the kernel cmdline to workaround the missing RSDP issue. For older version of kernels (Before 5.0), there won't be any change of behavior. Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>