[PATCH 00/11] crashkernel=auto: support fadump, reserve extra SWIOTLB memory and remove crashkernel.default
by Coiby Xu
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-fo...
[2] https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1171
[3] https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.o...
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
11 months, 2 weeks
[PATCH] mkdumprd: allow spaces after 'path' config phrase when network dump
by Kazuhito Hagio
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
1 year
[PATCH v2] Failback to default compression method if zstd fails
by Tao Liu
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
1 year, 3 months
[PATCH] fix broken kdump_get_arch_recommend_size
by Coiby Xu
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
1 year, 4 months
[PATCH v2] fix the error of parsing the container environ variable for osbuild
by Coiby Xu
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
1 year, 4 months
[PATCH] remove the upper bound of 102400T for the range in default crashkernel
by Coiby Xu
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
1 year, 4 months
[PATCH v2] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
by Philipp Rudo
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.ht...
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...
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.ht...
+
+ 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...
+
+ 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
1 year, 4 months
[PATCH] mkdumprd: support using an fs overlay for building initrd
by Kairui Song
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.o...
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
1 year, 4 months
[PATCH] s390: handle R_390_PLT32DBL reloc entries in machine_apply_elf_rel()
by Philipp Rudo
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.ht...
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...
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.ht...
+
+ 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...
+
+ 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
1 year, 4 months