summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* LoongArch: kdump: Set up kernel image segmentHEADmastermainYouling Tang2023-03-085-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>
* kexec: __NR_kexec_file_load is set to undefined on LoongArchYouling Tang2023-03-081-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>
* ppc64: Add elf-ppc64 file types/options and an arch specific flag to man pageGautam Menghani2023-03-031-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>
* x86: add devicetree supportJulian Winkler2023-02-237-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>
* kexec: make -a the defaultAhelenia Ziemiańska2023-02-072-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>
* ppc64: add --reuse-cmdline parameter supportSourabh Jain2023-02-072-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>
* kexec-tools 2.0.26.gitSimon Horman2023-02-071-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>
* kexec-tools 2.0.26v2.0.26Simon Horman2022-12-211-1/+1
| | | | Signed-off-by: Simon Horman <horms@kernel.org>
* kexec-tools 2.0.26-rc1v2.0.26-rc1Simon Horman2022-12-071-1/+1
| | | | Signed-off-by: Simon Horman <horms@kernel.org>
* m68k: pass rng seed via BI_RNG_SEEDJason A. Donenfeld2022-11-183-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>
* workflow: update to checkout@v3Simon Horman2022-10-281-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>
* LoongArch: Remove redundant cmdline parameters when using --reuse-cmdline optionYouling Tang2022-10-103-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>
* LoongArch: Add purgatory framework codeYouling Tang2022-10-105-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>
* LoongArch: PE format image loading supportYouling Tang2022-10-106-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>
* LoongArch: Add kexec/kdump supportYouling Tang2022-10-1014-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>
* config: Add LoongArch architecture support in config.guess and config.sub filesYouling Tang2022-10-102-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>
* ppc64: remove rma_top limitSourabh Jain2022-10-051-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>
* kexec-tools 2.0.25.gitSimon Horman2022-07-311-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>
* kexec-tools 2.0.25v2.0.25Simon Horman2022-07-311-1/+1
| | | | Signed-off-by: Simon Horman <horms@kernel.org>
* kexec-tools 2.0.25-rc1v2.0.25-rc1Simon Horman2022-07-191-1/+1
| | | | Signed-off-by: Simon Horman <horms@kernel.org>
* kexec-tools: Remove duplicate ultoa() definitions and redefine itTiezhu Yang2022-07-196-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>
* i386: pass rng seed via setup_dataJason A. Donenfeld2022-07-151-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>
* kexec-tools: mips: Pass initrd parameter via cmdlineHui Li2022-06-263-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>
* arm64/crashdump-arm64: increase CRASH_MAX_MEMORY_RANGES to 32kabuehaze142022-04-291-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>
* kexec-tools 2.0.23.gitSimon Horman2022-04-291-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>
* kexec-tools 2.0.24v2.0.24Simon Horman2022-04-091-1/+1
| | | | Signed-off-by: Simon Horman <horms@verge.net.au>
* kexec-tools 2.0.24-rc1v2.0.24-rc1Simon Horman2022-04-011-1/+1
| | | | Signed-off-by: Simon Horman <horms@verge.net.au>
* arm64: fix static data relocations in machine_apply_elf_rel()Pingfan Liu2022-04-011-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>
* kexec/elf: assign one to align if sh_addralign equals zeroPingfan Liu2022-04-011-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>
* arm64/crashdump-arm64: explicit type conversion to suppress compiler warningPingfan Liu2022-04-011-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>
* arm64/kexec-arm64: add support for R_AARCH64_MOVW_UABS_G* relaPingfan Liu2022-04-011-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>
* arm64/kexec-arm64: use enum to organize the reloc typePingfan Liu2022-04-011-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>
* arm64/kexec-arm64: add support for R_AARCH64_LDST128_ABS_LO12_NC relaPingfan Liu2022-04-011-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>
* kexec-tools: fix leak FILE pointer.Lichen Liu2022-03-301-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>
* purgatory: do not enable vectorization automatically for purgatory compilingBaoquan He2022-03-301-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>
* kexec-tools: Determine if the image is lzma commpressedLichen Liu2022-03-291-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>
* util_lib/elf_info: harden parsing of printk bufferPhilipp Rudo2022-03-241-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>
* github: run apt-get update before installing packagesSimon Horman2022-03-241-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>
* kexec-xen: Allow xen_kexec_exec() to return in case of Live UpdateRaphael Ning2022-03-233-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>
* kexec-tools: print error if kexec_file_load failsHari Bathini2022-03-231-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>
* kexec-tools: mips: Concatenate --reuse-cmdline and --appendTiezhu Yang2022-02-011-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>
* kexec-tools: mips: Add some debug infoTiezhu Yang2022-02-011-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>
* arm64: fix PAGE_OFFSET calc for flipped mmKairui Song2022-01-241-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>
* arm64: read VA_BITS from kcore for 52-bits VA kernelPingfan Liu2022-01-243-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>
* arm64/crashdump: unify routine to get page_offsetPingfan Liu2022-01-243-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>
* arm64: make phys_offset signedPingfan Liu2022-01-244-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>
* s390: add support for --reuse-cmdlineSven Schnelle2022-01-142-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>
* use slurp_proc_file() in get_command_line()Sven Schnelle2022-01-141-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>
* add slurp_proc_file()Sven Schnelle2022-01-141-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>
* s390: use KEXEC_ALL_OPTIONSSven Schnelle2022-01-141-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>
View Lorry Controller Status