74c68b80 — Sigrid Solveig Haflínudóttir 1 year, 2 months ago plan9
Merge remote-tracking branch 'upstream/main' into plan9
kexec-tools: mips: Pass initrd parameter via cmdline

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 32k

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>
2ddfaf31 — Simon Horman 1 year, 5 months ago
kexec-tools 2.0.23.git

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>
1d82b3fa — Simon Horman 1 year, 5 months ago
kexec-tools 2.0.24

Signed-off-by: Simon Horman <horms@verge.net.au>
272af539 — Simon Horman 1 year, 6 months ago
kexec-tools 2.0.24-rc1

Signed-off-by: Simon Horman <horms@verge.net.au>
c1ae085b — Pingfan Liu 1 year, 6 months ago
arm64: fix static data relocations in machine_apply_elf_rel()

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>
2b78a27a — Pingfan Liu 1 year, 6 months ago
kexec/elf: assign one to align if sh_addralign equals zero

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>
1d8273d8 — Pingfan Liu 1 year, 6 months ago
arm64/crashdump-arm64: explicit type conversion to suppress compiler warning

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>
33778949 — Pingfan Liu 1 year, 6 months ago
arm64/kexec-arm64: add support for R_AARCH64_MOVW_UABS_G* rela

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.

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>
e2a86b31 — Pingfan Liu 1 year, 6 months ago
arm64/kexec-arm64: use enum to organize the reloc type

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>
8e3f663a — Pingfan Liu 1 year, 6 months ago
arm64/kexec-arm64: add support for R_AARCH64_LDST128_ABS_LO12_NC rela

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>:
     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.

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 compiling

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:


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 commpressed

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 \
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>
f4c59879 — Philipp Rudo 1 year, 6 months ago
util_lib/elf_info: harden parsing of printk buffer

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>
30bfe30b — Simon Horman 1 year, 6 months ago
github: run apt-get update before installing packages

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>
501646be — Raphael Ning 1 year, 6 months ago
kexec-xen: Allow xen_kexec_exec() to return in case of Live Update

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>
1d7a308b — Hari Bathini 1 year, 6 months ago
kexec-tools: print error if kexec_file_load fails

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>
6effda06 — Tiezhu Yang 1 year, 8 months ago
kexec-tools: mips: Concatenate --reuse-cmdline and --append

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>