kexec January 2022

kexec@lists.fedoraproject.org

6 participants
29 discussions

[PATCH 00/11] crashkernel=auto: support fadump, reserve extra SWIOTLB memory and remove crashkernel.default
by Coiby Xu 16 Jun '22

16 Jun '22

The crashkernel=auto implementation in kernel space has been rejected upstream [1]. The current user space implementation [2] [3] ships a crashkernel.default but hasn't supported the swiotlb memory requirement, custom crashkernel value from user and fadump. The crashkernel.default implementation seems to be overly complex, - the default crashkernel value rarely changes. This is no need to ship the same crashkernel.default default for every kernel package of a architecture; - when deciding the value of crashkernel for a new kernel, the crashkernel.default of existing kernel is took into consideration We can simply let the kexec-tools maintain the default crashkernel values and provide an API for kdump-anacon-addon to query it. And for a newly installed kernel, we can simply call "kdumpctl reset-crashkernel KERNELPATH" to set its crashkernel value. For the unfulfilled requirements, - crashkernel is introduced to /etc/kdump.conf for the user can set custom crashkernel value to tell kexec-tools to manage crashkernel value automatically. - "kdumpctl reset-crashkernel" has been written for the above purpose. - "kdumpctl fadump on/off" is added for supporting fadump. [1] https://lore.kernel.org/linux-mm/20210507010432.IN24PudKT%25akpm@linux-foun… [2] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1171 [3] https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org… Coiby Xu (11): update default crashkernel value factor out kdump_get_arch_recommend_crashkernel provide get_default_crashkernel for kdump_anaconda_addon introduce crashkernel option to kdump.conf add a helper function to write a config value to kdump.conf add a helper function to read kernel cmdline parameter from grubby --info rewrite reset_crashkernel to provide more features for the user and to be called by kernel installation hook allow to add extra memory to crashkernel string Reserve extra memory when SME or SEV is active provide kdumpctl fadump on/off use "kdumpctl reset-crashkernel KERNELIMAGE" in kernel installation hook 92-crashkernel.install | 135 +---------------------------- kdump-lib-initramfs.sh | 9 ++ kdump-lib.sh | 95 +++++++++++++++------ kdump.conf | 6 ++ kdump.conf.5 | 7 ++ kdumpctl | 188 ++++++++++++++++++++++++++++++++++++----- kdumpctl.8 | 16 ++-- 7 files changed, 271 insertions(+), 185 deletions(-) -- 2.31.1

6 45

[PATCH] mkdumprd: allow spaces after 'path' config phrase when network dump
by Kazuhito Hagio 26 May '22

26 May '22

Without this patch, when there are two or more spaces after 'path' configuration phrase with ssh or nfs setting, SAVE_PATH is set to '/var/crash' in mkdumprd, and in most cases kdump service fails to start. ssh kdump(a)192.168.122.1 path /kdump ^^ This behavior would be too sensitive and different from the other configurations. With this patch, mkdumprd allows such spaces. Signed-off-by: Kazuhito Hagio <k-hagio(a)ab.jp.nec.com> --- mkdumprd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mkdumprd b/mkdumprd index a6f7fe8..aa0abfd 100644 --- a/mkdumprd +++ b/mkdumprd @@ -13,7 +13,7 @@ export IN_KDUMP=1 conf_file="/etc/kdump.conf" SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" -SAVE_PATH=$(grep ^path $conf_file| cut -d' ' -f2) +SAVE_PATH=$(awk '/^path/ {print $2}' $conf_file) [ -z "$SAVE_PATH" ] && SAVE_PATH=$DEFAULT_PATH # strip the duplicated "/" SAVE_PATH=$(echo $SAVE_PATH | tr -s /) -- 2.18.0

4 3

[PATCH v2] Failback to default compression method if zstd fails
by Tao Liu 14 Feb '22

14 Feb '22

Previously if users have not specified the compress method for kdump initramfs, "--compress zstd" will be appended to dracut cmdline. It will make dracut to decide: a) if dracut module squash is added, libzstd will be used, b) otherwise cmd zstd will be used. However in kexec-tools we cannot guarantee dracut module squash is added, for example users can set omit_dracutmodules in dracut.conf and etc, so is_squash_available is not able to check is libzstd or cmd zstd been used at runtime. This patch will give "--compress zstd" a try first, if fails, it will just proceed the default compression method, in order to avoid the error prone zstd/libzstd dependence check. Fixes: 7de4a0d ("Set zstd as recommented for kexec-tools") Signed-off-by: Tao Liu <ltao(a)redhat.com> --- v1 -> v2: Modified the commit message Notify user through ddebug if zstd-try fails, and redirect the error message to ddebug as well. --- kdump-lib.sh | 5 ----- mkdumprd | 23 ++++++++++++++--------- mkfadumprd | 9 +++++++-- 3 files changed, 21 insertions(+), 16 deletions(-) diff --git a/kdump-lib.sh b/kdump-lib.sh index 2ea51be..6415dda 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -31,11 +31,6 @@ is_squash_available() done } -is_zstd_command_available() -{ - [[ -x "$(command -v zstd)" ]] -} - perror_exit() { derror "$@" diff --git a/mkdumprd b/mkdumprd index 593ec77..0a81dc7 100644 --- a/mkdumprd +++ b/mkdumprd @@ -431,15 +431,6 @@ done <<< "$(kdump_read_conf)" handle_default_dump_target -if ! have_compression_in_dracut_args; then - # Here zstd is set as the default compression method. If squash module - # is available for dracut, libzstd will be used by mksquashfs. If - # squash module is unavailable, command zstd will be used instead. - if is_squash_available || is_zstd_command_available; then - add_dracut_arg "--compress" "zstd" - fi -fi - if [[ -n $extra_modules ]]; then add_dracut_arg "--add-drivers" "$extra_modules" fi @@ -457,6 +448,20 @@ if ! is_fadump_capable; then add_dracut_arg "--no-hostonly-default-device" fi +if ! have_compression_in_dracut_args; then + # Here we will first try to compress in zstd, if fails we will proceed + # the default compress method. + dracut "${dracut_args[@]}" "--compress" "zstd" "$@" 2> >(ddebug) + _rc=$? + + if [[ $_rc -eq 0 ]]; then + sync + exit $_rc + else + ddebug "Failback to default compress method" + fi +fi + dracut "${dracut_args[@]}" "$@" _rc=$? diff --git a/mkfadumprd b/mkfadumprd index 86dfcee..0d40975 100644 --- a/mkfadumprd +++ b/mkfadumprd @@ -64,8 +64,13 @@ fi # Same as setting zstd in mkdumprd if ! have_compression_in_dracut_args; then - if is_squash_available || is_zstd_command_available; then - _dracut_isolate_args+=(--compress zstd) + dracut --force --quiet "${_dracut_isolate_args[@]}" "--compress" "zstd" "$@" "$TARGET_INITRD" 2> >(ddebug) + _rc=$? + + if [[ $_rc -eq 0 ]]; then + exit $_rc + else + ddebug "Failback to default compress method for fadump" fi fi -- 2.33.1

4 9

[PATCH] fix broken kdump_get_arch_recommend_size
by Coiby Xu 26 Jan '22

26 Jan '22

s/ck_cmdline/_ck_cmdline to fix kdump_get_arch_recommend_size. Note s/sysmem/_sys_mem as well to make the changes consistent. Fixes: 105c016 ("factor out kdump_get_arch_recommend_crashkernel") Signed-off-by: Coiby Xu <coxu(a)redhat.com> --- kdump-lib.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kdump-lib.sh b/kdump-lib.sh index c6bdd2e..3e912cc 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -864,16 +864,16 @@ kdump_get_arch_recommend_crashkernel() # $1: kernel version, if not set, will defaults to $(uname -r) kdump_get_arch_recommend_size() { - local _ck_cmdline + local _ck_cmdline _sys_mem if ! [[ -r "/proc/iomem" ]]; then echo "Error, can not access /proc/iomem." return 1 fi - sys_mem=$(get_system_size) + _sys_mem=$(get_system_size) _ck_cmdline=$(kdump_get_arch_recommend_crashkernel) _ck_cmdline=${_ck_cmdline//-:/-102400T:} - get_recommend_size "$sys_mem" "$ck_cmdline" + get_recommend_size "$_sys_mem" "$_ck_cmdline" } # Print all underlying crypt devices of a block device -- 2.34.1

2 3

[PATCH v2] fix the error of parsing the container environ variable for osbuild
by Coiby Xu 25 Jan '22

25 Jan '22

The environment variable entries in /proc/[pid]/environ are separated by null bytes instead of by spaces. Update the sed regex to fix this issue. Note that, 1. this patch also fixes a issue which is kdumpctl would try to reset crashkernel even osbuild has provided custom crashkernel value. 2. kernel hook 92-crashkernel.install installed by kexec-tools is guaranteed to be ran by kernel-install. kexec-tools doesn't recommend kernel so there is no guarantee kernel is installed after kexec-tools. But dnf invokes kernel-install in the posttrans scriptlet (of kernel-core) which is always ran after all packages including kexec-tools and kernel in a dnf transaction. 3. To be able to do unit tests, the logic of reading environment variable has been extracted as a separate function. Fixes: ddd428a ("set up kernel crashkernel for osbuild in kernel hook") Signed-off-by: Coiby Xu <coxu(a)redhat.com> --- kdumpctl | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/kdumpctl b/kdumpctl index 8107487..3ccfa97 100755 --- a/kdumpctl +++ b/kdumpctl @@ -1576,9 +1576,19 @@ reset_crashkernel_after_update() done } +# read the value of an environ variable from given environ file path +# +# The environment variable entries in /proc/[pid]/environ are separated +# by null bytes instead of by spaces. +read_proc_environ_var() +{ + local _environ_path=$1 _var=$2 + sed -n -E "s/.*(^|\x00)${_var}=([^\x00]*).*/\2/p" < "$_environ_path" +} + _is_osbuild() { - [[ $(sed -n -E 's/.*(^|\s)container=(\S*).*/\2/p' < /proc/1/environ) == bwrap-osbuild ]] + [[ $(read_proc_environ_var container /proc/1/environ) == bwrap-osbuild ]] } reset_crashkernel_for_installed_kernel() @@ -1590,8 +1600,10 @@ reset_crashkernel_for_installed_kernel() exit 1 fi - if _is_osbuild && ! grep -qs crashkernel= /etc/kernel/cmdline; then - reset_crashkernel "--kernel=$_installed_kernel" + if _is_osbuild; then + if ! grep -qs crashkernel= /etc/kernel/cmdline; then + reset_crashkernel "--kernel=$_installed_kernel" + fi return fi -- 2.31.1

2 3

[PATCH] remove the upper bound of 102400T for the range in default crashkernel
by Coiby Xu 25 Jan '22

25 Jan '22

This patch makes the default crashkernel value consistent with previous one. Fixes: 105c016 ("factor out kdump_get_arch_recommend_crashkernel") Signed-off-by: Coiby Xu <coxu(a)redhat.com> --- kdump-lib.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kdump-lib.sh b/kdump-lib.sh index 0e64f22..79f7248 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -861,7 +861,6 @@ kdump_get_arch_recommend_crashkernel() fi fi - _ck_cmdline=${_ck_cmdline//-:/-102400T:} echo -n "$_ck_cmdline" } @@ -877,6 +876,7 @@ kdump_get_arch_recommend_size() fi sys_mem=$(get_system_size) _ck_cmdline=$(kdump_get_arch_recommend_crashkernel) + _ck_cmdline=${_ck_cmdline//-:/-102400T:} get_recommend_size "$sys_mem" "$ck_cmdline" } -- 2.34.1

2 2

[PATCH v2] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
by Philipp Rudo 25 Jan '22

25 Jan '22

Resolves: bz2025860 Upstream: git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git commit 186e7b0752d8fce1618fa37519671c834c46340e Author: Alexander Egorenkov <egorenar(a)linux.ibm.com> Date: Wed Dec 15 18:48:53 2021 +0100 s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel() 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… 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.i… Signed-off-by: Alexander Egorenkov <egorenar(a)linux.ibm.com> Reported-by: Tao Liu <ltao(a)redhat.com> Suggested-by: Philipp Rudo <prudo(a)redhat.com> Reviewed-by: Philipp Rudo <prudo(a)redhat.com> [hca(a)linux.ibm.com: changed commit message as requested by Philipp Rudo] Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com> Signed-off-by: Simon Horman <horms(a)verge.net.au> v2: - Moved patch 601 -> 401 Signed-off-by: Philipp Rudo <prudo(a)redhat.com> --- ...oc_entries_in_machine_apply_elf_rel_.patch | 95 +++++++++++++++++++ kexec-tools.spec | 3 + 2 files changed, 98 insertions(+) create mode 100644 kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machine_apply_elf_rel_.patch diff --git a/kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machine_apply_elf_rel_.patch b/kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machine_apply_elf_rel_.patch new file mode 100644 index 0000000..10bc5ef --- /dev/null +++ b/kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machine_apply_elf_rel_.patch @@ -0,0 +1,95 @@ +commit 186e7b0752d8fce1618fa37519671c834c46340e +Author: Alexander Egorenkov <egorenar(a)linux.ibm.com> +Date: Wed Dec 15 18:48:53 2021 +0100 + + s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel() + + 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… + + 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.i… + + Signed-off-by: Alexander Egorenkov <egorenar(a)linux.ibm.com> + Reported-by: Tao Liu <ltao(a)redhat.com> + Suggested-by: Philipp Rudo <prudo(a)redhat.com> + Reviewed-by: Philipp Rudo <prudo(a)redhat.com> + [hca(a)linux.ibm.com: changed commit message as requested by Philipp Rudo] + Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com> + Signed-off-by: Simon Horman <horms(a)verge.net.au> + +diff --git a/kexec/arch/s390/kexec-elf-rel-s390.c b/kexec/arch/s390/kexec-elf-rel-s390.c +index a5e1b73455785ae3bc3aa72b3beee13ae202e82f..91ba86a9991dad4271b834fc3b24861c40309e52 100644 +--- a/kexec/arch/s390/kexec-elf-rel-s390.c ++++ b/kexec/arch/s390/kexec-elf-rel-s390.c +@@ -56,6 +56,7 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr), + case R_390_PC16: /* PC relative 16 bit. */ + case R_390_PC16DBL: /* PC relative 16 bit shifted by 1. */ + case R_390_PC32DBL: /* PC relative 32 bit shifted by 1. */ ++ case R_390_PLT32DBL: /* 32 bit PC rel. PLT shifted by 1. */ + case R_390_PC32: /* PC relative 32 bit. */ + case R_390_PC64: /* PC relative 64 bit. */ + val -= address; +@@ -63,7 +64,7 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr), + *(unsigned short *) loc = val; + else if (r_type == R_390_PC16DBL) + *(unsigned short *) loc = val >> 1; +- else if (r_type == R_390_PC32DBL) ++ else if (r_type == R_390_PC32DBL || r_type == R_390_PLT32DBL) + *(unsigned int *) loc = val >> 1; + else if (r_type == R_390_PC32) + *(unsigned int *) loc = val; diff --git a/kexec-tools.spec b/kexec-tools.spec index 9f7118b..5c34e67 100644 --- a/kexec-tools.spec +++ b/kexec-tools.spec @@ -103,6 +103,7 @@ Requires: systemd-udev%{?_isa} # # Patches 401 through 500 are meant for s390 kexec-tools enablement # +Patch401: ./kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machine_apply_elf_rel_.patch # # Patches 501 through 600 are meant for ARM kexec-tools enablement @@ -126,6 +127,8 @@ mkdir -p -m755 kcp tar -z -x -v -f %{SOURCE9} tar -z -x -v -f %{SOURCE19} +%patch401 -p1 + %ifarch ppc %define archdef ARCH=ppc %endif -- 2.34.1

2 1

[PATCH] Revert "Remove trace_buf_size and trace_event from the kernel bootparameters of the kdump kernel"
by Tao Liu 25 Jan '22

25 Jan '22

There is a mechanism to keep memory consumption minimum, i.e. equal to trace_buf_size=1, until tracing by ftrace is actually started: tracing: keep ring buffer to minimum size till used https://github.com/torvalds/linux/commit/73c5162aa362a543793f4a957c6c536dcb… Since ftrace is usually never used in the kdump 2nd kernel, the kdump 2nd kernel behaves in the same way with or without trace_buf_size=1. So the issue which the patch want to solve never exists. Let's revert the patch for better maintainance and avoid confusion. ref link: https://bugzilla.redhat.com/show_bug.cgi?id=2034501#c20 This reverts commit f39000f Signed-off-by: Tao Liu <ltao(a)redhat.com> --- kdump-lib.sh | 4 ---- 1 file changed, 4 deletions(-) diff --git a/kdump-lib.sh b/kdump-lib.sh index ca086d7..b7827ef 100755 --- a/kdump-lib.sh +++ b/kdump-lib.sh @@ -784,10 +784,6 @@ prepare_cmdline() fi done - # Remove trace_buf_size, trace_event - cmdline=$(remove_cmdline_param "$cmdline" trace_buf_size trace_event) - cmdline="${cmdline} trace_buf_size=1" - echo "$cmdline" } -- 2.33.1

2 1

[PATCH] mkdumprd: support using an fs overlay for building initrd
by Kairui Song 25 Jan '22

25 Jan '22

From: Kairui Song <kasong(a)tencent.com> Currently kdump simply uses dracut and pulls all the required binaries from the host directly. This keep things simple as kdump is using same binaries and libs from the system of fisrt kernel. But some binaries, like systemd, is growing too large, which increase the memory usage by a lot, and most of its features are never used in kdump. So it's more reasonable to use a rebuilt-minimized version. So for such binaries, introduce a "build root" overlay here. Before calling dracut to build initramfs, setup an overlay to let the build root override current rootfs, so dracut can just work as usual, but the binaries used are from the "build root". All binaries/libs that need to be rebuild for smaller size can be put in the build root. Signed-off-by: Kairui Song <kasong(a)tencent.com> --- Hi, I'm trying again to make this package into Fedora: https://github.com/ryncsn/kdump-initrd-systemd It's a minimized version of systemd, as kdump heavily depend on systemd and so using a minimized version of systemd just for kdump can help a lot for saving memory. But it need to depend on kexec-tools for the present of this dir: `$RPM_BUILD_ROOT%{_prefix}/lib/buildroot` So this patch have to be merged first, then selinux rule need to be updated, then that kdump-initrd-systemd package can pass rpm checks and get included in Fedora. I've sent the patch previously and got acked by Pingfan, but it didn't get merged that time: https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org… There have been many updated to kexec-tools so I rebased this patch to latest rawhide. Next steps are: 1. Discuss and get this patch merged, and make a new kexec-tools release. 2. Open a bug for SELinux rules to let mkdumprd have access to buildroot path. SELinux team will need the code base from kexec-tools as reference the SELinux rule update. 3. Introduce that package (and maybe other minimized package) to Fedora. I've tested this on some cloud instances, which show a great improvement in memory usage: With kdump-initrd-systemd [debug_mem] kdump saving vmcore MemTotal: 90084 kB MemFree: 18612 kB MemAvailable: 49004 kB Without kdump-initrd-systemd [debug_mem] kdump saving vmcore MemTotal: 90084 kB MemFree: 9492 kB MemAvailable: 39800 kB Which is a good start point, as systemd can be minimized even more, and some libraries are still being depended on by other packaged, which can also be minimized later. Systemd is a big part of the initramfs that can't be stirpped easily so the repackaged version will be very helpful. kexec-tools.spec | 1 + mkdumprd | 20 +++++++++++++++++++- 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/kexec-tools.spec b/kexec-tools.spec index 849d09c..c90a60a 100644 --- a/kexec-tools.spec +++ b/kexec-tools.spec @@ -173,6 +173,7 @@ mkdir -p $RPM_BUILD_ROOT%{_unitdir} mkdir -p -m755 $RPM_BUILD_ROOT%{_bindir} mkdir -p -m755 $RPM_BUILD_ROOT%{_libdir} mkdir -p -m755 $RPM_BUILD_ROOT%{_prefix}/lib/kdump +mkdir -p -m755 $RPM_BUILD_ROOT%{_prefix}/lib/buildroot mkdir -p -m755 $RPM_BUILD_ROOT%{_sharedstatedir}/kdump install -m 755 %{SOURCE1} $RPM_BUILD_ROOT%{_bindir}/kdumpctl diff --git a/mkdumprd b/mkdumprd index 593ec77..386f55a 100644 --- a/mkdumprd +++ b/mkdumprd @@ -22,6 +22,7 @@ if ! dlog_init; then exit 1 fi +KDUMP_BUILDROOT="/usr/lib/kdump/buildroot" SSH_KEY_LOCATION="/root/.ssh/kdump_id_rsa" SAVE_PATH=$(get_save_path) OVERRIDE_RESETTABLE=0 @@ -32,11 +33,13 @@ dracut_args=(--add kdumpbase --quiet --hostonly --hostonly-cmdline --hostonly-i1 MKDUMPRD_TMPDIR="$(mktemp -d -t mkdumprd.XXXXXX)" [ -d "$MKDUMPRD_TMPDIR" ] || perror_exit "dracut: mktemp -p -d -t dracut.XXXXXX failed." MKDUMPRD_TMPMNT="$MKDUMPRD_TMPDIR/target" +MKDUMPRD_TMPROOT="$MKDUMPRD_TMPDIR/root" trap ' ret=$?; is_mounted $MKDUMPRD_TMPMNT && umount -f $MKDUMPRD_TMPMNT; [[ -d $MKDUMPRD_TMPDIR ]] && rm --one-file-system -rf -- "$MKDUMPRD_TMPDIR"; + [[ -d $MKDUMPRD_TMPROOT ]] && rm --one-file-system -rf -- "$MKDUMPRD_TMPROOT"; exit $ret; ' EXIT @@ -457,7 +460,22 @@ if ! is_fadump_capable; then add_dracut_arg "--no-hostonly-default-device" fi -dracut "${dracut_args[@]}" "$@" +if [ -e $KDUMP_BUILDROOT/usr ] || [ -e $KDUMP_BUILDROOT/etc ]; then + # Run in a new namespace, so overlay on root is safe + # everything is automatically cleaned up upon exit + export KDUMP_BUILDROOT + export MKDUMPRD_TMPROOT + + cp -r /usr/lib/kdump/buildroot "$MKDUMPRD_TMPROOT" + unshare --mount bash -c ' + for _d in etc usr; do + [ -d "$MKDUMPRD_TMPROOT/$_d" ] && \ + mount overlay -t overlay -o ro,lowerdir=$MKDUMPRD_TMPROOT/$_d:/$_d /$_d; + done + dracut "$@"' _ "${dracut_args[@]}" "$@" +else + dracut "${dracut_args[@]}" "$@" +fi _rc=$? sync -- 2.34.1

2 5

[PATCH] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
by Philipp Rudo 25 Jan '22

25 Jan '22

Resolves: bz2025860 Upstream: git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git commit 186e7b0752d8fce1618fa37519671c834c46340e Author: Alexander Egorenkov <egorenar(a)linux.ibm.com> Date: Wed Dec 15 18:48:53 2021 +0100 s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel() 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… 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.i… Signed-off-by: Alexander Egorenkov <egorenar(a)linux.ibm.com> Reported-by: Tao Liu <ltao(a)redhat.com> Suggested-by: Philipp Rudo <prudo(a)redhat.com> Reviewed-by: Philipp Rudo <prudo(a)redhat.com> [hca(a)linux.ibm.com: changed commit message as requested by Philipp Rudo] Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com> Signed-off-by: Simon Horman <horms(a)verge.net.au> Signed-off-by: Philipp Rudo <prudo(a)redhat.com> --- ...oc_entries_in_machine_apply_elf_rel_.patch | 95 +++++++++++++++++++ kexec-tools.spec | 3 + 2 files changed, 98 insertions(+) create mode 100644 kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machine_apply_elf_rel_.patch diff --git a/kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machine_apply_elf_rel_.patch b/kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machine_apply_elf_rel_.patch new file mode 100644 index 0000000..10bc5ef --- /dev/null +++ b/kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machine_apply_elf_rel_.patch @@ -0,0 +1,95 @@ +commit 186e7b0752d8fce1618fa37519671c834c46340e +Author: Alexander Egorenkov <egorenar(a)linux.ibm.com> +Date: Wed Dec 15 18:48:53 2021 +0100 + + s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel() + + 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… + + 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.i… + + Signed-off-by: Alexander Egorenkov <egorenar(a)linux.ibm.com> + Reported-by: Tao Liu <ltao(a)redhat.com> + Suggested-by: Philipp Rudo <prudo(a)redhat.com> + Reviewed-by: Philipp Rudo <prudo(a)redhat.com> + [hca(a)linux.ibm.com: changed commit message as requested by Philipp Rudo] + Signed-off-by: Heiko Carstens <hca(a)linux.ibm.com> + Signed-off-by: Simon Horman <horms(a)verge.net.au> + +diff --git a/kexec/arch/s390/kexec-elf-rel-s390.c b/kexec/arch/s390/kexec-elf-rel-s390.c +index a5e1b73455785ae3bc3aa72b3beee13ae202e82f..91ba86a9991dad4271b834fc3b24861c40309e52 100644 +--- a/kexec/arch/s390/kexec-elf-rel-s390.c ++++ b/kexec/arch/s390/kexec-elf-rel-s390.c +@@ -56,6 +56,7 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr), + case R_390_PC16: /* PC relative 16 bit. */ + case R_390_PC16DBL: /* PC relative 16 bit shifted by 1. */ + case R_390_PC32DBL: /* PC relative 32 bit shifted by 1. */ ++ case R_390_PLT32DBL: /* 32 bit PC rel. PLT shifted by 1. */ + case R_390_PC32: /* PC relative 32 bit. */ + case R_390_PC64: /* PC relative 64 bit. */ + val -= address; +@@ -63,7 +64,7 @@ void machine_apply_elf_rel(struct mem_ehdr *UNUSED(ehdr), + *(unsigned short *) loc = val; + else if (r_type == R_390_PC16DBL) + *(unsigned short *) loc = val >> 1; +- else if (r_type == R_390_PC32DBL) ++ else if (r_type == R_390_PC32DBL || r_type == R_390_PLT32DBL) + *(unsigned int *) loc = val >> 1; + else if (r_type == R_390_PC32) + *(unsigned int *) loc = val; diff --git a/kexec-tools.spec b/kexec-tools.spec index 7419723..f687449 100644 --- a/kexec-tools.spec +++ b/kexec-tools.spec @@ -110,6 +110,7 @@ Requires: systemd-udev%{?_isa} # # Patches 601 onward are generic patches # +Patch601: ./kexec-tools-2.0.23-s390_handle_R_390_PLT32DBL_reloc_entries_in_machine_apply_elf_rel_.patch %description kexec-tools provides /sbin/kexec binary that facilitates a new @@ -125,6 +126,8 @@ mkdir -p -m755 kcp tar -z -x -v -f %{SOURCE9} tar -z -x -v -f %{SOURCE19} +%patch601 -p1 + %ifarch ppc %define archdef ARCH=ppc %endif -- 2.34.1

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

kexec January 2022