[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, 6 months
Re: [dm-crypt] Kdump with full-disk LUKS encryption
by Kairui Song
Hi,
Thanks a lot, these info are very helpful.
Better to keep it for debugging for now, and ask users to use it very carefully.
On Tue, Apr 20, 2021 at 3:54 PM Milan Broz <gmazyland(a)gmail.com> wrote:
>
> Hi,
>
> TL;DR what you are trying to do is to actually reverse many security measures
> we added. It is perhaps acceptable for debugging but hardly for real generic system.
>
> - using memory-hard function increases cost of dictionary and brute-force
> attacks
> You can always decrease amount of memory needed, but you should do it only
> if you know that security margin is ok (like password is randomly generated
> with enough entropy).
>
> - key is in keyring to remove possibility for normal userspace to receive
> the key from kernel. Moreover, there is no need to retain kernel in keyring once
> dm-crypt device is activated. (It is still in kernel memory but only in crypto
> functions context). (Systemd also uses keyring to cache passphrase but that's
> different thing.)
>
> You can still use old way for activation with --disable-keyring activation,
> but then you disable this possibility.
>
> More comments below.
>
> On 19/04/2021 12:00, Kairui Song wrote:
> > Hi all,
> >
> > I'm currently trying to add kdump support for systemd with full-disk
> > LUKS encryption. vmcores contain sensitive data so they should also be
> > protected, and network dumps sometimes are not available. So kdump has
> > to open the LUKS encrypted device in the kdump environment.
> >
> > I'm using systemd/dracut, my work machine is running Fedora 34, and
> > there are several problems I'm trying to solve:
> > 1. Users have to input the password in the kdump kernel environment.
> > But users often don't have shell access to the kdump environment.
> > (headless server, graphic card not working after kexec, both are very
> > common)
> > 2. LUKS2 prefers Argon2 as the key derivation function, designed to
> > use a lot of memory. kdump is expected to use a minimal amount of
> > memory. Users will have to reserve a huge amount of memory for kdump
> > to work (eg. 1G reserve for kdump with 4G total memory which is not
> > reasonable).
>
> When I added Argon2 to LUKS2, I actually expected such issues. Despite
> some people beats me that they cannot use arbitrary amount of memory,
> we have some hard limits that were selected that it should work on most recent
> systems. Maybe kdump can live with it.
>
> - maximum memory cost limit is 4GB, no LUKS2 device can use more for Argon2
> - we never use more than half of available physical memory
> (measured on the host where the device was formatted)
> - required amount of memory is visible in LUKS2 metadata (luksDump)
> for the particular keyslot (Memory: the value is in kB)
> - we use benchmark to calculate memory cost with prefered unlocking
> time 2 seconds (again, on the device where LUKS was formatted)
> Small systems (like RPi2) the uses much smaller acceptable values.
> You can configure all costs (time, memory, threads) during format
> or even set them to predefined values.
>
> I am sorry, but there is really no way around this - and the requeired
> memory must be physical memory (otherwise it slows down extremely).
> This is a feature, not a bug :-)
>
>
> > To fix these problems, I tried to pass the master key to the second
> > kernel directly via initramfs. Kdump will modify the initramfs in
> > ramfs to include the key, kexec_load it, and never write to any actual
> > back storage. This worked with old LUKS configurations.
>
> Well, passing volume key this way is quite insecure, but perhaps
> acceptable for debugging.
>
> >
> > But LUKS2/cryptsetup now stores the key in the kernel keyring by
> > default. The key is accessible from userspace.
>
> If you are talking about volume key (not passsphrase), it is not
> available from userspace. Only reference to it. But you can use
> this reference to construct in-kernel dm-crypt device.
> Please read https://gitlab.com/cryptsetup/cryptsetup/-/blob/master/docs/Keyring.txt
>
> > Users can enter the password to start kdump manually and then it will
> > work, but usually people expect kdump service to start automatically.
> >
> > (WIP patch series:
> > https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.o...)
> >
> > I've several ideas about how to improve it but not sure which one is
> > better, and if this is a good idea after all:
> > 1. Simply introduce a config to let systemd-cryptsetup disable kernel
> > keyring on setup, there is currently no such option.
>
> Well, that option could be useful anyway and we have support for it
> in cryptsetup (--disable-keyring CLI option) and libcryptsetup, so why not.
> Just this should not be a default option.
>
> This is should be patch for systemd-cryptsetup only as libcryptsetup supports it.
>
> ...
>
> > 2. If we can let the key stay in userspace for a little longer, eg.
> > for systems booted with dracut/systemd, when
> > systemd-cryptsetup(a)%s.service opens the crypt device, keep the key in
> > dm-crypt. And later when services like kdump have finished loading,
> > cryptsetup can refresh the device and store the key in the kernel
> > keyring again.
>
> We invalidate volume key in keyring after libceyposetup operation
> is finished (and kernel removes the reference once keyring garbage collection
> is run).
>
> I can imagine to add some option to keep key inside keyring even after
> call is finished, but as said above, this removes some security margin
> we intentionally introduced here.
I agree with your comments, thanks! These two approaches seem not a
good idea now.
>
> ...
>
> Milan
>
How about plan 3 and 4?
> 3. Let kdump use some custom helper/service to load all needed
> resources in the early initrd boot stage, prior to
> systemd-cryptsetup(a)%s.service. It will ask the password / parse the
> keyfile and load kdump, then provide info for systemd-cryptsetup or
> just do the setup. Or maybe let systemd-cryptsetup support some kind
> of "plugins" so other tools can use it.
Some details could be changed/improved, but
systemd-cryptsetup(a)%s.service will prompt for a password or use a
keyfile anyway.
So I think at this point, loading kdump with the volume key should be
safe? At least long as the kdump kernel/environment itself isn't
compromised. Loaded kdump resources can be restricted to be only
accessible from the kernel side.
After panic, kernel kexec jumps to kdump kernel, and that's an
minimized emergency environment that only lives for a very short
period.
> 4. A better and safer solution seems to keep a consistent key ring
> between kexec boots but also more complex and difficult as different
> arch implements kexec differently.
Maybe plan 4 will be a good idea if doable? Since that keeps the key
consistent in the kernel between kexec boots, and cryptsetup can just
reuse it.
--
Best Regards,
Kairui Song
2 years, 1 month
[PATCH v2 0/7] Set up kdump network by "nmcli --get-values"
by Coiby Xu
ifcfg scripts are deprecated. kexec-tools still set up network
based on ifcfg scripts which lead to the issues like [1] [2].
We can get network configuration including dns, bond and znet by
parsing nmcli output instead. Another benefit is we could potentially
avoid subtle bugs caused by namespace pollution because of sourcing
ifcfg scripts.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1919052
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1933679
v1 -> v2:
- Use "nmcli --get-values" to extract the value by filed directly [Kairui]
- Keep compatibility with network scripts [Kairui]
- kdumpctl will exit when failing to set up znet or bond cmdline
- Warn the user when network scripts are used
dracut-module-setup.sh | 105 +++++++++++++++++++++++++++++++----------
kdump-lib.sh | 48 +++++++++++++++++++
2 files changed, 128 insertions(+), 25 deletions(-)
--
2.31.0
2 years, 6 months
[PATCH] Disable CMA in kdump 2nd kernel
by Tao Liu
kexec-tools needs to disable CMA for kdump kernel cmdline,
otherwise kdump kernel may run out of memory.
This patch strips the inherited cma=, hugetlb_cma= cmd
line from 1st kernel, and sets to be 0 for 2nd kernel.
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
kdump.sysconfig | 4 ++--
kdump.sysconfig.aarch64 | 4 ++--
kdump.sysconfig.i386 | 4 ++--
kdump.sysconfig.ppc64 | 4 ++--
kdump.sysconfig.ppc64le | 4 ++--
kdump.sysconfig.s390x | 4 ++--
kdump.sysconfig.x86_64 | 4 ++--
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/kdump.sysconfig b/kdump.sysconfig
index 30f0c63..70ebf04 100644
--- a/kdump.sysconfig
+++ b/kdump.sysconfig
@@ -17,11 +17,11 @@ KDUMP_COMMANDLINE=""
# This variable lets us remove arguments from the current kdump commandline
# as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline
# NOTE: some arguments such as crashkernel will always be removed
-KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
+KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb cma hugetlb_cma"
# This variable lets us append arguments to the current kdump commandline
# after processed by KDUMP_COMMANDLINE_REMOVE
-KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 reset_devices novmcoredd"
+KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 reset_devices novmcoredd cma=0 hugetlb_cma=0"
# Any additional kexec arguments required. In most situations, this should
# be left empty
diff --git a/kdump.sysconfig.aarch64 b/kdump.sysconfig.aarch64
index 6f7830a..fedd3bc 100644
--- a/kdump.sysconfig.aarch64
+++ b/kdump.sysconfig.aarch64
@@ -17,11 +17,11 @@ KDUMP_COMMANDLINE=""
# This variable lets us remove arguments from the current kdump commandline
# as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline
# NOTE: some arguments such as crashkernel will always be removed
-KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
+KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb cma hugetlb_cma"
# This variable lets us append arguments to the current kdump commandline
# after processed by KDUMP_COMMANDLINE_REMOVE
-KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory udev.children-max=2 panic=10 swiotlb=noforce novmcoredd"
+KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory udev.children-max=2 panic=10 swiotlb=noforce novmcoredd cma=0 hugetlb_cma=0"
# Any additional kexec arguments required. In most situations, this should
# be left empty
diff --git a/kdump.sysconfig.i386 b/kdump.sysconfig.i386
index d2de7d6..7e18c1c 100644
--- a/kdump.sysconfig.i386
+++ b/kdump.sysconfig.i386
@@ -17,11 +17,11 @@ KDUMP_COMMANDLINE=""
# This variable lets us remove arguments from the current kdump commandline
# as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline
# NOTE: some arguments such as crashkernel will always be removed
-KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
+KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb cma hugetlb_cma"
# This variable lets us append arguments to the current kdump commandline
# after processed by KDUMP_COMMANDLINE_REMOVE
-KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices numa=off udev.children-max=2 panic=10 transparent_hugepage=never novmcoredd"
+KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices numa=off udev.children-max=2 panic=10 transparent_hugepage=never novmcoredd cma=0 hugetlb_cma=0"
# Any additional kexec arguments required. In most situations, this should
# be left empty
diff --git a/kdump.sysconfig.ppc64 b/kdump.sysconfig.ppc64
index 39b69bb..ebb22f6 100644
--- a/kdump.sysconfig.ppc64
+++ b/kdump.sysconfig.ppc64
@@ -17,11 +17,11 @@ KDUMP_COMMANDLINE=""
# This variable lets us remove arguments from the current kdump commandline
# as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline
# NOTE: some arguments such as crashkernel will always be removed
-KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
+KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb hugetlb_cma"
# This variable lets us append arguments to the current kdump commandline
# after processed by KDUMP_COMMANDLINE_REMOVE
-KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 noirqdistrib reset_devices cgroup_disable=memory numa=off udev.children-max=2 ehea.use_mcs=0 panic=10 kvm_cma_resv_ratio=0 transparent_hugepage=never novmcoredd"
+KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 noirqdistrib reset_devices cgroup_disable=memory numa=off udev.children-max=2 ehea.use_mcs=0 panic=10 kvm_cma_resv_ratio=0 transparent_hugepage=never novmcoredd hugetlb_cma=0"
# Any additional kexec arguments required. In most situations, this should
# be left empty
diff --git a/kdump.sysconfig.ppc64le b/kdump.sysconfig.ppc64le
index 39b69bb..ebb22f6 100644
--- a/kdump.sysconfig.ppc64le
+++ b/kdump.sysconfig.ppc64le
@@ -17,11 +17,11 @@ KDUMP_COMMANDLINE=""
# This variable lets us remove arguments from the current kdump commandline
# as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline
# NOTE: some arguments such as crashkernel will always be removed
-KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
+KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb hugetlb_cma"
# This variable lets us append arguments to the current kdump commandline
# after processed by KDUMP_COMMANDLINE_REMOVE
-KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 noirqdistrib reset_devices cgroup_disable=memory numa=off udev.children-max=2 ehea.use_mcs=0 panic=10 kvm_cma_resv_ratio=0 transparent_hugepage=never novmcoredd"
+KDUMP_COMMANDLINE_APPEND="irqpoll maxcpus=1 noirqdistrib reset_devices cgroup_disable=memory numa=off udev.children-max=2 ehea.use_mcs=0 panic=10 kvm_cma_resv_ratio=0 transparent_hugepage=never novmcoredd hugetlb_cma=0"
# Any additional kexec arguments required. In most situations, this should
# be left empty
diff --git a/kdump.sysconfig.s390x b/kdump.sysconfig.s390x
index f9218e5..439e462 100644
--- a/kdump.sysconfig.s390x
+++ b/kdump.sysconfig.s390x
@@ -17,11 +17,11 @@ KDUMP_COMMANDLINE=""
# This variable lets us remove arguments from the current kdump commandline
# as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline
# NOTE: some arguments such as crashkernel will always be removed
-KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
+KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb vmcp_cma cma hugetlb_cma"
# This variable lets us append arguments to the current kdump commandline
# after processed by KDUMP_COMMANDLINE_REMOVE
-KDUMP_COMMANDLINE_APPEND="nr_cpus=1 cgroup_disable=memory numa=off udev.children-max=2 panic=10 transparent_hugepage=never novmcoredd"
+KDUMP_COMMANDLINE_APPEND="nr_cpus=1 cgroup_disable=memory numa=off udev.children-max=2 panic=10 transparent_hugepage=never novmcoredd vmcp_cma=0 cma=0 hugetlb_cma=0"
# Any additional /sbin/mkdumprd arguments required.
MKDUMPRD_ARGS=""
diff --git a/kdump.sysconfig.x86_64 b/kdump.sysconfig.x86_64
index 0521893..1285506 100644
--- a/kdump.sysconfig.x86_64
+++ b/kdump.sysconfig.x86_64
@@ -17,11 +17,11 @@ KDUMP_COMMANDLINE=""
# This variable lets us remove arguments from the current kdump commandline
# as taken from either KDUMP_COMMANDLINE above, or from /proc/cmdline
# NOTE: some arguments such as crashkernel will always be removed
-KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb"
+KDUMP_COMMANDLINE_REMOVE="hugepages hugepagesz slub_debug quiet log_buf_len swiotlb cma hugetlb_cma"
# This variable lets us append arguments to the current kdump commandline
# after processed by KDUMP_COMMANDLINE_REMOVE
-KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 acpi_no_memhotplug transparent_hugepage=never nokaslr hest_disable novmcoredd"
+KDUMP_COMMANDLINE_APPEND="irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 acpi_no_memhotplug transparent_hugepage=never nokaslr hest_disable novmcoredd cma=0 hugetlb_cma=0"
# Any additional kexec arguments required. In most situations, this should
# be left empty
--
2.29.2
2 years, 6 months
[PATCH] makedumpfile: arm64: support flipped VA and 52-bit kernel VA
by Pingfan Liu
Linux 5.4 and later kernels for arm64 changed the kernel VA space
arrangement and introduced 52-bit kernel VAs by merging branch
commit b333b0ba2346. Support 5.9+ kernels with vmcoreinfo entries
and 5.4+ kernels with best guessing.
However, the following conditions are not supported for now due to
no necessary information provided from kernel:
(1) 5.4 <= kernels <= 5.8 and
- if PA_BITS=52 && VA_BITS!=52
- with -x option if vabits_actual=52
(2) kernels < 5.4 with CONFIG_ARM64_USER_VA_BITS_52=y
(1) should be supported with kernel commit bbdbc11804ff and
1d50e5d0c5052 adding necessary information to vmcoreinfo.
Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
---
...coreinfo-note-in-proc-kcore-for-mem-.patch | 146 +++++++++++
...Make-use-of-NUMBER-VA_BITS-in-vmcore.patch | 101 ++++++++
...support-flipped-VA-and-52-bit-kernel.patch | 245 ++++++++++++++++++
kexec-tools.spec | 7 +
4 files changed, 499 insertions(+)
create mode 100644 kexec-tools-2.0.21-makedumpfile-PATCH-1-3-Use-vmcoreinfo-note-in-proc-kcore-for-mem-.patch
create mode 100644 kexec-tools-2.0.21-makedumpfile-PATCH-2-3-arm64-Make-use-of-NUMBER-VA_BITS-in-vmcore.patch
create mode 100644 kexec-tools-2.0.21-makedumpfile-PATCH-3-3-arm64-support-flipped-VA-and-52-bit-kernel.patch
diff --git a/kexec-tools-2.0.21-makedumpfile-PATCH-1-3-Use-vmcoreinfo-note-in-proc-kcore-for-mem-.patch b/kexec-tools-2.0.21-makedumpfile-PATCH-1-3-Use-vmcoreinfo-note-in-proc-kcore-for-mem-.patch
new file mode 100644
index 0000000..316d1b4
--- /dev/null
+++ b/kexec-tools-2.0.21-makedumpfile-PATCH-1-3-Use-vmcoreinfo-note-in-proc-kcore-for-mem-.patch
@@ -0,0 +1,146 @@
+From d8b701796f0491f2ac4b06c7a5b795c29399efab Mon Sep 17 00:00:00 2001
+From: Kazuhito Hagio <k-hagio-ab(a)nec.com>
+Date: Fri, 29 Jan 2021 11:40:23 +0900
+Subject: [PATCH 1/3] [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for
+ --mem-usage option
+
+kernel commit 23c85094fe18 added vmcoreinfo note to /proc/kcore.
+Use the vmcoreinfo note to get necessary information, especially
+page_offset and phys_base on arm64, for the --mem-usage option.
+
+Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
+---
+ elf_info.c | 49 -------------------------------------------------
+ elf_info.h | 1 -
+ makedumpfile.c | 26 +++++++++++++++++++++-----
+ 3 files changed, 21 insertions(+), 55 deletions(-)
+
+diff --git a/makedumpfile-1.6.8/elf_info.c b/makedumpfile-1.6.8/elf_info.c
+index a6624b5..e8affb7 100644
+--- a/makedumpfile-1.6.8/elf_info.c
++++ b/makedumpfile-1.6.8/elf_info.c
+@@ -698,55 +698,6 @@ get_elf32_ehdr(int fd, char *filename, Elf32_Ehdr *ehdr)
+ return TRUE;
+ }
+
+-int
+-get_elf_loads(int fd, char *filename)
+-{
+- int i, j, phnum, elf_format;
+- Elf64_Phdr phdr;
+-
+- /*
+- * Check ELF64 or ELF32.
+- */
+- elf_format = check_elf_format(fd, filename, &phnum, &num_pt_loads);
+- if (elf_format == ELF64)
+- flags_memory |= MEMORY_ELF64;
+- else if (elf_format != ELF32)
+- return FALSE;
+-
+- if (!num_pt_loads) {
+- ERRMSG("Can't get the number of PT_LOAD.\n");
+- return FALSE;
+- }
+-
+- /*
+- * The below file information will be used as /proc/vmcore.
+- */
+- fd_memory = fd;
+- name_memory = filename;
+-
+- pt_loads = calloc(sizeof(struct pt_load_segment), num_pt_loads);
+- if (pt_loads == NULL) {
+- ERRMSG("Can't allocate memory for the PT_LOAD. %s\n",
+- strerror(errno));
+- return FALSE;
+- }
+- for (i = 0, j = 0; i < phnum; i++) {
+- if (!get_phdr_memory(i, &phdr))
+- return FALSE;
+-
+- if (phdr.p_type != PT_LOAD)
+- continue;
+-
+- if (j >= num_pt_loads)
+- return FALSE;
+- if (!dump_Elf_load(&phdr, j))
+- return FALSE;
+- j++;
+- }
+-
+- return TRUE;
+-}
+-
+ static int exclude_segment(struct pt_load_segment **pt_loads,
+ unsigned int *num_pt_loads, uint64_t start, uint64_t end)
+ {
+diff --git a/makedumpfile-1.6.8/elf_info.h b/makedumpfile-1.6.8/elf_info.h
+index d9b5d05..d5416b3 100644
+--- a/makedumpfile-1.6.8/elf_info.h
++++ b/makedumpfile-1.6.8/elf_info.h
+@@ -44,7 +44,6 @@ int get_elf64_ehdr(int fd, char *filename, Elf64_Ehdr *ehdr);
+ int get_elf32_ehdr(int fd, char *filename, Elf32_Ehdr *ehdr);
+ int get_elf_info(int fd, char *filename);
+ void free_elf_info(void);
+-int get_elf_loads(int fd, char *filename);
+ int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t vmcoreinfo_len);
+ int get_kcore_dump_loads(void);
+
+diff --git a/makedumpfile-1.6.8/makedumpfile.c b/makedumpfile-1.6.8/makedumpfile.c
+index ba0003a..768eda4 100644
+--- a/makedumpfile-1.6.8/makedumpfile.c
++++ b/makedumpfile-1.6.8/makedumpfile.c
+@@ -11445,6 +11445,7 @@ int show_mem_usage(void)
+ {
+ uint64_t vmcoreinfo_addr, vmcoreinfo_len;
+ struct cycle cycle = {0};
++ int vmcoreinfo = FALSE;
+
+ if (!is_crashkernel_mem_reserved()) {
+ ERRMSG("No memory is reserved for crashkernel!\n");
+@@ -11456,9 +11457,22 @@ int show_mem_usage(void)
+ if (!open_files_for_creating_dumpfile())
+ return FALSE;
+
+- if (!get_elf_loads(info->fd_memory, info->name_memory))
++ if (!get_elf_info(info->fd_memory, info->name_memory))
+ return FALSE;
+
++ /*
++ * /proc/kcore on Linux 4.19 and later kernels have vmcoreinfo note in
++ * NOTE segment. See commit 23c85094fe18.
++ */
++ if (has_vmcoreinfo()) {
++ off_t offset;
++ unsigned long size;
++
++ get_vmcoreinfo(&offset, &size);
++ vmcoreinfo = read_vmcoreinfo_from_vmcore(offset, size, FALSE);
++ DEBUG_MSG("Read vmcoreinfo from NOTE segment: %d\n", vmcoreinfo);
++ }
++
+ if (!get_page_offset())
+ return FALSE;
+
+@@ -11466,11 +11480,13 @@ int show_mem_usage(void)
+ if (!get_phys_base())
+ return FALSE;
+
+- if (!get_sys_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
+- return FALSE;
++ if (!vmcoreinfo) {
++ if (!get_sys_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
++ return FALSE;
+
+- if (!set_kcore_vmcoreinfo(vmcoreinfo_addr, vmcoreinfo_len))
+- return FALSE;
++ if (!set_kcore_vmcoreinfo(vmcoreinfo_addr, vmcoreinfo_len))
++ return FALSE;
++ }
+
+ if (!initial())
+ return FALSE;
+--
+2.29.2
+
diff --git a/kexec-tools-2.0.21-makedumpfile-PATCH-2-3-arm64-Make-use-of-NUMBER-VA_BITS-in-vmcore.patch b/kexec-tools-2.0.21-makedumpfile-PATCH-2-3-arm64-Make-use-of-NUMBER-VA_BITS-in-vmcore.patch
new file mode 100644
index 0000000..e29a0c0
--- /dev/null
+++ b/kexec-tools-2.0.21-makedumpfile-PATCH-2-3-arm64-Make-use-of-NUMBER-VA_BITS-in-vmcore.patch
@@ -0,0 +1,101 @@
+From 67d0e1d68f28c567a704fd6b9b8fd696ad3df183 Mon Sep 17 00:00:00 2001
+From: Kazuhito Hagio <k-hagio-ab(a)nec.com>
+Date: Fri, 29 Jan 2021 11:40:24 +0900
+Subject: [PATCH 2/3] [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in
+ vmcoreinfo
+
+Make use of the NUMBER(VA_BITS) in vmcoreinfo, which was added by
+kernel commit 20a166243328 (Linux 4.12 and later kernels), as the
+current way of guessing VA_BITS does not work on Linux 5.4 and
+later kernels.
+
+Signed-off-by: Bhupesh Sharma <bhsharma(a)redhat.com>
+Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
+---
+ arch/arm64.c | 63 ++++++++++++++++++++++++++++++++++------------------
+ 1 file changed, 42 insertions(+), 21 deletions(-)
+
+diff --git a/makedumpfile-1.6.8/arch/arm64.c b/makedumpfile-1.6.8/arch/arm64.c
+index 3d7b416..2916b4f 100644
+--- a/makedumpfile-1.6.8/arch/arm64.c
++++ b/makedumpfile-1.6.8/arch/arm64.c
+@@ -345,6 +345,43 @@ get_stext_symbol(void)
+ return(found ? kallsym : FALSE);
+ }
+
++static int
++get_va_bits_from_stext_arm64(void)
++{
++ ulong _stext;
++
++ _stext = get_stext_symbol();
++ if (!_stext) {
++ ERRMSG("Can't get the symbol of _stext.\n");
++ return FALSE;
++ }
++
++ /*
++ * Derive va_bits as per arch/arm64/Kconfig. Note that this is a
++ * best case approximation at the moment, as there can be
++ * inconsistencies in this calculation (for e.g., for 52-bit
++ * kernel VA case, the 48th bit is set in * the _stext symbol).
++ */
++ if ((_stext & PAGE_OFFSET_48) == PAGE_OFFSET_48) {
++ va_bits = 48;
++ } else if ((_stext & PAGE_OFFSET_47) == PAGE_OFFSET_47) {
++ va_bits = 47;
++ } else if ((_stext & PAGE_OFFSET_42) == PAGE_OFFSET_42) {
++ va_bits = 42;
++ } else if ((_stext & PAGE_OFFSET_39) == PAGE_OFFSET_39) {
++ va_bits = 39;
++ } else if ((_stext & PAGE_OFFSET_36) == PAGE_OFFSET_36) {
++ va_bits = 36;
++ } else {
++ ERRMSG("Cannot find a proper _stext for calculating VA_BITS\n");
++ return FALSE;
++ }
++
++ DEBUG_MSG("va_bits : %d (guess from _stext)\n", va_bits);
++
++ return TRUE;
++}
++
+ int
+ get_machdep_info_arm64(void)
+ {
+@@ -398,27 +435,11 @@ get_xen_info_arm64(void)
+ int
+ get_versiondep_info_arm64(void)
+ {
+- ulong _stext;
+-
+- _stext = get_stext_symbol();
+- if (!_stext) {
+- ERRMSG("Can't get the symbol of _stext.\n");
+- return FALSE;
+- }
+-
+- /* Derive va_bits as per arch/arm64/Kconfig */
+- if ((_stext & PAGE_OFFSET_36) == PAGE_OFFSET_36) {
+- va_bits = 36;
+- } else if ((_stext & PAGE_OFFSET_39) == PAGE_OFFSET_39) {
+- va_bits = 39;
+- } else if ((_stext & PAGE_OFFSET_42) == PAGE_OFFSET_42) {
+- va_bits = 42;
+- } else if ((_stext & PAGE_OFFSET_47) == PAGE_OFFSET_47) {
+- va_bits = 47;
+- } else if ((_stext & PAGE_OFFSET_48) == PAGE_OFFSET_48) {
+- va_bits = 48;
+- } else {
+- ERRMSG("Cannot find a proper _stext for calculating VA_BITS\n");
++ if (NUMBER(VA_BITS) != NOT_FOUND_NUMBER) {
++ va_bits = NUMBER(VA_BITS);
++ DEBUG_MSG("va_bits : %d (vmcoreinfo)\n", va_bits);
++ } else if (get_va_bits_from_stext_arm64() == FALSE) {
++ ERRMSG("Can't determine va_bits.\n");
+ return FALSE;
+ }
+
+--
+2.29.2
+
diff --git a/kexec-tools-2.0.21-makedumpfile-PATCH-3-3-arm64-support-flipped-VA-and-52-bit-kernel.patch b/kexec-tools-2.0.21-makedumpfile-PATCH-3-3-arm64-support-flipped-VA-and-52-bit-kernel.patch
new file mode 100644
index 0000000..752bb07
--- /dev/null
+++ b/kexec-tools-2.0.21-makedumpfile-PATCH-3-3-arm64-support-flipped-VA-and-52-bit-kernel.patch
@@ -0,0 +1,245 @@
+From a0216b678a95f099a16172cc4a67ad5aa6a89583 Mon Sep 17 00:00:00 2001
+From: Kazuhito Hagio <k-hagio-ab(a)nec.com>
+Date: Fri, 29 Jan 2021 11:40:25 +0900
+Subject: [PATCH 3/3] [PATCH 3/3] arm64: support flipped VA and 52-bit kernel
+ VA
+
+Linux 5.4 and later kernels for arm64 changed the kernel VA space
+arrangement and introduced 52-bit kernel VAs by merging branch
+commit b333b0ba2346. Support 5.9+ kernels with vmcoreinfo entries
+and 5.4+ kernels with best guessing.
+
+However, the following conditions are not supported for now due to
+no necessary information provided from kernel:
+(1) 5.4 <= kernels <= 5.8 and
+ - if PA_BITS=52 && VA_BITS!=52
+ - with -x option if vabits_actual=52
+(2) kernels < 5.4 with CONFIG_ARM64_USER_VA_BITS_52=y
+
+(1) should be supported with kernel commit bbdbc11804ff and
+1d50e5d0c5052 adding necessary information to vmcoreinfo.
+
+Signed-off-by: Bhupesh Sharma <bhsharma(a)redhat.com>
+Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
+Reviewed-by: Pingfan Liu <piliu(a)redhat.com>
+---
+ arch/arm64.c | 100 +++++++++++++++++++++++++++++++++++++++++--------
+ makedumpfile.c | 2 +
+ makedumpfile.h | 1 +
+ 3 files changed, 88 insertions(+), 15 deletions(-)
+
+diff --git a/makedumpfile-1.6.8/arch/arm64.c b/makedumpfile-1.6.8/arch/arm64.c
+index 2916b4f..1072178 100644
+--- a/makedumpfile-1.6.8/arch/arm64.c
++++ b/makedumpfile-1.6.8/arch/arm64.c
+@@ -47,6 +47,8 @@ typedef struct {
+ static int lpa_52_bit_support_available;
+ static int pgtable_level;
+ static int va_bits;
++static int vabits_actual;
++static int flipped_va;
+ static unsigned long kimage_voffset;
+
+ #define SZ_4K 4096
+@@ -58,7 +60,6 @@ static unsigned long kimage_voffset;
+ #define PAGE_OFFSET_42 ((0xffffffffffffffffUL) << 42)
+ #define PAGE_OFFSET_47 ((0xffffffffffffffffUL) << 47)
+ #define PAGE_OFFSET_48 ((0xffffffffffffffffUL) << 48)
+-#define PAGE_OFFSET_52 ((0xffffffffffffffffUL) << 52)
+
+ #define pgd_val(x) ((x).pgd)
+ #define pud_val(x) (pgd_val((x).pgd))
+@@ -218,12 +219,20 @@ pmd_page_paddr(pmd_t pmd)
+ #define pte_index(vaddr) (((vaddr) >> PAGESHIFT()) & (PTRS_PER_PTE - 1))
+ #define pte_offset(dir, vaddr) (pmd_page_paddr((*dir)) + pte_index(vaddr) * sizeof(pte_t))
+
++/*
++ * The linear kernel range starts at the bottom of the virtual address
++ * space. Testing the top bit for the start of the region is a
++ * sufficient check and avoids having to worry about the tag.
++ */
++#define is_linear_addr(addr) (flipped_va ? \
++ (!((unsigned long)(addr) & (1UL << (vabits_actual - 1)))) : \
++ (!!((unsigned long)(addr) & (1UL << (vabits_actual - 1)))))
++
+ static unsigned long long
+ __pa(unsigned long vaddr)
+ {
+- if (kimage_voffset == NOT_FOUND_NUMBER ||
+- (vaddr >= PAGE_OFFSET))
+- return (vaddr - PAGE_OFFSET + info->phys_base);
++ if (kimage_voffset == NOT_FOUND_NUMBER || is_linear_addr(vaddr))
++ return ((vaddr & ~PAGE_OFFSET) + info->phys_base);
+ else
+ return (vaddr - kimage_voffset);
+ }
+@@ -253,6 +262,7 @@ static int calculate_plat_config(void)
+ (PAGESIZE() == SZ_64K && va_bits == 42)) {
+ pgtable_level = 2;
+ } else if ((PAGESIZE() == SZ_64K && va_bits == 48) ||
++ (PAGESIZE() == SZ_64K && va_bits == 52) ||
+ (PAGESIZE() == SZ_4K && va_bits == 39) ||
+ (PAGESIZE() == SZ_16K && va_bits == 47)) {
+ pgtable_level = 3;
+@@ -263,6 +273,7 @@ static int calculate_plat_config(void)
+ PAGESIZE(), va_bits);
+ return FALSE;
+ }
++ DEBUG_MSG("pgtable_level: %d\n", pgtable_level);
+
+ return TRUE;
+ }
+@@ -270,6 +281,9 @@ static int calculate_plat_config(void)
+ unsigned long
+ get_kvbase_arm64(void)
+ {
++ if (flipped_va)
++ return PAGE_OFFSET;
++
+ return (0xffffffffffffffffUL << va_bits);
+ }
+
+@@ -382,22 +396,54 @@ get_va_bits_from_stext_arm64(void)
+ return TRUE;
+ }
+
++static void
++get_page_offset_arm64(void)
++{
++ ulong page_end;
++ int vabits_min;
++
++ /*
++ * See arch/arm64/include/asm/memory.h for more details of
++ * the PAGE_OFFSET calculation.
++ */
++ vabits_min = (va_bits > 48) ? 48 : va_bits;
++ page_end = -(1UL << (vabits_min - 1));
++
++ if (SYMBOL(_stext) > page_end) {
++ flipped_va = TRUE;
++ info->page_offset = -(1UL << vabits_actual);
++ } else {
++ flipped_va = FALSE;
++ info->page_offset = -(1UL << (vabits_actual - 1));
++ }
++
++ DEBUG_MSG("page_offset : %lx (from page_end check)\n",
++ info->page_offset);
++}
++
+ int
+ get_machdep_info_arm64(void)
+ {
++ /* Check if va_bits is still not initialized. If still 0, call
++ * get_versiondep_info() to initialize the same.
++ */
++ if (!va_bits)
++ get_versiondep_info_arm64();
++
+ /* Determine if the PA address range is 52-bits: ARMv8.2-LPA */
+ if (NUMBER(MAX_PHYSMEM_BITS) != NOT_FOUND_NUMBER) {
+ info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS);
++ DEBUG_MSG("max_physmem_bits : %ld (vmcoreinfo)\n", info->max_physmem_bits);
+ if (info->max_physmem_bits == 52)
+ lpa_52_bit_support_available = 1;
+- } else
+- info->max_physmem_bits = 48;
++ } else {
++ if (va_bits == 52)
++ info->max_physmem_bits = 52; /* just guess */
++ else
++ info->max_physmem_bits = 48;
+
+- /* Check if va_bits is still not initialized. If still 0, call
+- * get_versiondep_info() to initialize the same.
+- */
+- if (!va_bits)
+- get_versiondep_info_arm64();
++ DEBUG_MSG("max_physmem_bits : %ld (guess)\n", info->max_physmem_bits);
++ }
+
+ if (!calculate_plat_config()) {
+ ERRMSG("Can't determine platform config values\n");
+@@ -408,7 +454,6 @@ get_machdep_info_arm64(void)
+ info->section_size_bits = SECTIONS_SIZE_BITS;
+
+ DEBUG_MSG("kimage_voffset : %lx\n", kimage_voffset);
+- DEBUG_MSG("max_physmem_bits : %ld\n", info->max_physmem_bits);
+ DEBUG_MSG("section_size_bits: %ld\n", info->section_size_bits);
+
+ return TRUE;
+@@ -443,10 +488,35 @@ get_versiondep_info_arm64(void)
+ return FALSE;
+ }
+
+- info->page_offset = (0xffffffffffffffffUL) << (va_bits - 1);
++ /*
++ * See TCR_EL1, Translation Control Register (EL1) register
++ * description in the ARMv8 Architecture Reference Manual.
++ * Basically, we can use the TCR_EL1.T1SZ value to determine
++ * the virtual addressing range supported in the kernel-space
++ * (i.e. vabits_actual) since Linux 5.9.
++ */
++ if (NUMBER(TCR_EL1_T1SZ) != NOT_FOUND_NUMBER) {
++ vabits_actual = 64 - NUMBER(TCR_EL1_T1SZ);
++ DEBUG_MSG("vabits_actual : %d (vmcoreinfo)\n", vabits_actual);
++ } else if ((va_bits == 52) && (SYMBOL(mem_section) != NOT_FOUND_SYMBOL)) {
++ /*
++ * Linux 5.4 through 5.10 have the following linear space:
++ * 48-bit: 0xffff000000000000 - 0xffff7fffffffffff
++ * 52-bit: 0xfff0000000000000 - 0xfff7ffffffffffff
++ * and SYMBOL(mem_section) should be in linear space if
++ * the kernel is configured with COMFIG_SPARSEMEM_EXTREME=y.
++ */
++ if (SYMBOL(mem_section) & (1UL << (va_bits - 1)))
++ vabits_actual = 48;
++ else
++ vabits_actual = 52;
++ DEBUG_MSG("vabits_actual : %d (guess from mem_section)\n", vabits_actual);
++ } else {
++ vabits_actual = va_bits;
++ DEBUG_MSG("vabits_actual : %d (same as va_bits)\n", vabits_actual);
++ }
+
+- DEBUG_MSG("va_bits : %d\n", va_bits);
+- DEBUG_MSG("page_offset : %lx\n", info->page_offset);
++ get_page_offset_arm64();
+
+ return TRUE;
+ }
+diff --git a/makedumpfile-1.6.8/makedumpfile.c b/makedumpfile-1.6.8/makedumpfile.c
+index 768eda4..fcd766b 100644
+--- a/makedumpfile-1.6.8/makedumpfile.c
++++ b/makedumpfile-1.6.8/makedumpfile.c
+@@ -2397,6 +2397,7 @@ write_vmcoreinfo_data(void)
+ WRITE_NUMBER("HUGETLB_PAGE_DTOR", HUGETLB_PAGE_DTOR);
+ #ifdef __aarch64__
+ WRITE_NUMBER("VA_BITS", VA_BITS);
++ /* WRITE_NUMBER("TCR_EL1_T1SZ", TCR_EL1_T1SZ); should not exists */
+ WRITE_NUMBER_UNSIGNED("PHYS_OFFSET", PHYS_OFFSET);
+ WRITE_NUMBER_UNSIGNED("kimage_voffset", kimage_voffset);
+ #endif
+@@ -2836,6 +2837,7 @@ read_vmcoreinfo(void)
+ READ_NUMBER("KERNEL_IMAGE_SIZE", KERNEL_IMAGE_SIZE);
+ #ifdef __aarch64__
+ READ_NUMBER("VA_BITS", VA_BITS);
++ READ_NUMBER("TCR_EL1_T1SZ", TCR_EL1_T1SZ);
+ READ_NUMBER_UNSIGNED("PHYS_OFFSET", PHYS_OFFSET);
+ READ_NUMBER_UNSIGNED("kimage_voffset", kimage_voffset);
+ #endif
+diff --git a/makedumpfile-1.6.8/makedumpfile.h b/makedumpfile-1.6.8/makedumpfile.h
+index 0ed6417..97a5554 100644
+--- a/makedumpfile-1.6.8/makedumpfile.h
++++ b/makedumpfile-1.6.8/makedumpfile.h
+@@ -2049,6 +2049,7 @@ struct number_table {
+ long KERNEL_IMAGE_SIZE;
+ #ifdef __aarch64__
+ long VA_BITS;
++ long TCR_EL1_T1SZ;
+ unsigned long PHYS_OFFSET;
+ unsigned long kimage_voffset;
+ #endif
+--
+2.29.2
+
diff --git a/kexec-tools.spec b/kexec-tools.spec
index 69a89d5..0da4382 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -96,6 +96,10 @@ Requires: systemd-udev%{?_isa}
#
# Patches 501 through 600 are meant for ARM kexec-tools enablement
#
+Patch501: ./kexec-tools-2.0.21-makedumpfile-PATCH-1-3-Use-vmcoreinfo-note-in-proc-kcore-for-mem-.patch
+Patch502: ./kexec-tools-2.0.21-makedumpfile-PATCH-2-3-arm64-Make-use-of-NUMBER-VA_BITS-in-vmcore.patch
+Patch503: ./kexec-tools-2.0.21-makedumpfile-PATCH-3-3-arm64-support-flipped-VA-and-52-bit-kernel.patch
+
#
# Patches 601 onward are generic patches
@@ -121,6 +125,9 @@ mkdir -p -m755 kcp
tar -z -x -v -f %{SOURCE9}
tar -z -x -v -f %{SOURCE19}
+%patch501 -p1
+%patch502 -p1
+%patch503 -p1
%patch603 -p1
%patch604 -p1
%patch605 -p1
--
2.29.2
2 years, 7 months
[PATCH] makedumpfile: arm64: support flipped VA and 52-bit kernel VA
by Pingfan Liu
Linux 5.4 and later kernels for arm64 changed the kernel VA space
arrangement and introduced 52-bit kernel VAs by merging branch
commit b333b0ba2346. Support 5.9+ kernels with vmcoreinfo entries
and 5.4+ kernels with best guessing.
However, the following conditions are not supported for now due to
no necessary information provided from kernel:
(1) 5.4 <= kernels <= 5.8 and
- if PA_BITS=52 && VA_BITS!=52
- with -x option if vabits_actual=52
(2) kernels < 5.4 with CONFIG_ARM64_USER_VA_BITS_52=y
(1) should be supported with kernel commit bbdbc11804ff and
1d50e5d0c5052 adding necessary information to vmcoreinfo.
Signed-off-by: Pingfan Liu <piliu(a)redhat.com>
---
...coreinfo-note-in-proc-kcore-for-mem-.patch | 146 +++++++++++
...Make-use-of-NUMBER-VA_BITS-in-vmcore.patch | 101 ++++++++
...support-flipped-VA-and-52-bit-kernel.patch | 245 ++++++++++++++++++
kexec-tools.spec | 7 +
4 files changed, 499 insertions(+)
create mode 100644 kexec-tools-2.0.21-makedumpfile-PATCH-1-3-Use-vmcoreinfo-note-in-proc-kcore-for-mem-.patch
create mode 100644 kexec-tools-2.0.21-makedumpfile-PATCH-2-3-arm64-Make-use-of-NUMBER-VA_BITS-in-vmcore.patch
create mode 100644 kexec-tools-2.0.21-makedumpfile-PATCH-3-3-arm64-support-flipped-VA-and-52-bit-kernel.patch
diff --git a/kexec-tools-2.0.21-makedumpfile-PATCH-1-3-Use-vmcoreinfo-note-in-proc-kcore-for-mem-.patch b/kexec-tools-2.0.21-makedumpfile-PATCH-1-3-Use-vmcoreinfo-note-in-proc-kcore-for-mem-.patch
new file mode 100644
index 0000000..316d1b4
--- /dev/null
+++ b/kexec-tools-2.0.21-makedumpfile-PATCH-1-3-Use-vmcoreinfo-note-in-proc-kcore-for-mem-.patch
@@ -0,0 +1,146 @@
+From d8b701796f0491f2ac4b06c7a5b795c29399efab Mon Sep 17 00:00:00 2001
+From: Kazuhito Hagio <k-hagio-ab(a)nec.com>
+Date: Fri, 29 Jan 2021 11:40:23 +0900
+Subject: [PATCH 1/3] [PATCH 1/3] Use vmcoreinfo note in /proc/kcore for
+ --mem-usage option
+
+kernel commit 23c85094fe18 added vmcoreinfo note to /proc/kcore.
+Use the vmcoreinfo note to get necessary information, especially
+page_offset and phys_base on arm64, for the --mem-usage option.
+
+Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
+---
+ elf_info.c | 49 -------------------------------------------------
+ elf_info.h | 1 -
+ makedumpfile.c | 26 +++++++++++++++++++++-----
+ 3 files changed, 21 insertions(+), 55 deletions(-)
+
+diff --git a/makedumpfile-1.6.8/elf_info.c b/makedumpfile-1.6.8/elf_info.c
+index a6624b5..e8affb7 100644
+--- a/makedumpfile-1.6.8/elf_info.c
++++ b/makedumpfile-1.6.8/elf_info.c
+@@ -698,55 +698,6 @@ get_elf32_ehdr(int fd, char *filename, Elf32_Ehdr *ehdr)
+ return TRUE;
+ }
+
+-int
+-get_elf_loads(int fd, char *filename)
+-{
+- int i, j, phnum, elf_format;
+- Elf64_Phdr phdr;
+-
+- /*
+- * Check ELF64 or ELF32.
+- */
+- elf_format = check_elf_format(fd, filename, &phnum, &num_pt_loads);
+- if (elf_format == ELF64)
+- flags_memory |= MEMORY_ELF64;
+- else if (elf_format != ELF32)
+- return FALSE;
+-
+- if (!num_pt_loads) {
+- ERRMSG("Can't get the number of PT_LOAD.\n");
+- return FALSE;
+- }
+-
+- /*
+- * The below file information will be used as /proc/vmcore.
+- */
+- fd_memory = fd;
+- name_memory = filename;
+-
+- pt_loads = calloc(sizeof(struct pt_load_segment), num_pt_loads);
+- if (pt_loads == NULL) {
+- ERRMSG("Can't allocate memory for the PT_LOAD. %s\n",
+- strerror(errno));
+- return FALSE;
+- }
+- for (i = 0, j = 0; i < phnum; i++) {
+- if (!get_phdr_memory(i, &phdr))
+- return FALSE;
+-
+- if (phdr.p_type != PT_LOAD)
+- continue;
+-
+- if (j >= num_pt_loads)
+- return FALSE;
+- if (!dump_Elf_load(&phdr, j))
+- return FALSE;
+- j++;
+- }
+-
+- return TRUE;
+-}
+-
+ static int exclude_segment(struct pt_load_segment **pt_loads,
+ unsigned int *num_pt_loads, uint64_t start, uint64_t end)
+ {
+diff --git a/makedumpfile-1.6.8/elf_info.h b/makedumpfile-1.6.8/elf_info.h
+index d9b5d05..d5416b3 100644
+--- a/makedumpfile-1.6.8/elf_info.h
++++ b/makedumpfile-1.6.8/elf_info.h
+@@ -44,7 +44,6 @@ int get_elf64_ehdr(int fd, char *filename, Elf64_Ehdr *ehdr);
+ int get_elf32_ehdr(int fd, char *filename, Elf32_Ehdr *ehdr);
+ int get_elf_info(int fd, char *filename);
+ void free_elf_info(void);
+-int get_elf_loads(int fd, char *filename);
+ int set_kcore_vmcoreinfo(uint64_t vmcoreinfo_addr, uint64_t vmcoreinfo_len);
+ int get_kcore_dump_loads(void);
+
+diff --git a/makedumpfile-1.6.8/makedumpfile.c b/makedumpfile-1.6.8/makedumpfile.c
+index ba0003a..768eda4 100644
+--- a/makedumpfile-1.6.8/makedumpfile.c
++++ b/makedumpfile-1.6.8/makedumpfile.c
+@@ -11445,6 +11445,7 @@ int show_mem_usage(void)
+ {
+ uint64_t vmcoreinfo_addr, vmcoreinfo_len;
+ struct cycle cycle = {0};
++ int vmcoreinfo = FALSE;
+
+ if (!is_crashkernel_mem_reserved()) {
+ ERRMSG("No memory is reserved for crashkernel!\n");
+@@ -11456,9 +11457,22 @@ int show_mem_usage(void)
+ if (!open_files_for_creating_dumpfile())
+ return FALSE;
+
+- if (!get_elf_loads(info->fd_memory, info->name_memory))
++ if (!get_elf_info(info->fd_memory, info->name_memory))
+ return FALSE;
+
++ /*
++ * /proc/kcore on Linux 4.19 and later kernels have vmcoreinfo note in
++ * NOTE segment. See commit 23c85094fe18.
++ */
++ if (has_vmcoreinfo()) {
++ off_t offset;
++ unsigned long size;
++
++ get_vmcoreinfo(&offset, &size);
++ vmcoreinfo = read_vmcoreinfo_from_vmcore(offset, size, FALSE);
++ DEBUG_MSG("Read vmcoreinfo from NOTE segment: %d\n", vmcoreinfo);
++ }
++
+ if (!get_page_offset())
+ return FALSE;
+
+@@ -11466,11 +11480,13 @@ int show_mem_usage(void)
+ if (!get_phys_base())
+ return FALSE;
+
+- if (!get_sys_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
+- return FALSE;
++ if (!vmcoreinfo) {
++ if (!get_sys_kernel_vmcoreinfo(&vmcoreinfo_addr, &vmcoreinfo_len))
++ return FALSE;
+
+- if (!set_kcore_vmcoreinfo(vmcoreinfo_addr, vmcoreinfo_len))
+- return FALSE;
++ if (!set_kcore_vmcoreinfo(vmcoreinfo_addr, vmcoreinfo_len))
++ return FALSE;
++ }
+
+ if (!initial())
+ return FALSE;
+--
+2.29.2
+
diff --git a/kexec-tools-2.0.21-makedumpfile-PATCH-2-3-arm64-Make-use-of-NUMBER-VA_BITS-in-vmcore.patch b/kexec-tools-2.0.21-makedumpfile-PATCH-2-3-arm64-Make-use-of-NUMBER-VA_BITS-in-vmcore.patch
new file mode 100644
index 0000000..e29a0c0
--- /dev/null
+++ b/kexec-tools-2.0.21-makedumpfile-PATCH-2-3-arm64-Make-use-of-NUMBER-VA_BITS-in-vmcore.patch
@@ -0,0 +1,101 @@
+From 67d0e1d68f28c567a704fd6b9b8fd696ad3df183 Mon Sep 17 00:00:00 2001
+From: Kazuhito Hagio <k-hagio-ab(a)nec.com>
+Date: Fri, 29 Jan 2021 11:40:24 +0900
+Subject: [PATCH 2/3] [PATCH 2/3] arm64: Make use of NUMBER(VA_BITS) in
+ vmcoreinfo
+
+Make use of the NUMBER(VA_BITS) in vmcoreinfo, which was added by
+kernel commit 20a166243328 (Linux 4.12 and later kernels), as the
+current way of guessing VA_BITS does not work on Linux 5.4 and
+later kernels.
+
+Signed-off-by: Bhupesh Sharma <bhsharma(a)redhat.com>
+Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
+---
+ arch/arm64.c | 63 ++++++++++++++++++++++++++++++++++------------------
+ 1 file changed, 42 insertions(+), 21 deletions(-)
+
+diff --git a/makedumpfile-1.6.8/arch/arm64.c b/makedumpfile-1.6.8/arch/arm64.c
+index 3d7b416..2916b4f 100644
+--- a/makedumpfile-1.6.8/arch/arm64.c
++++ b/makedumpfile-1.6.8/arch/arm64.c
+@@ -345,6 +345,43 @@ get_stext_symbol(void)
+ return(found ? kallsym : FALSE);
+ }
+
++static int
++get_va_bits_from_stext_arm64(void)
++{
++ ulong _stext;
++
++ _stext = get_stext_symbol();
++ if (!_stext) {
++ ERRMSG("Can't get the symbol of _stext.\n");
++ return FALSE;
++ }
++
++ /*
++ * Derive va_bits as per arch/arm64/Kconfig. Note that this is a
++ * best case approximation at the moment, as there can be
++ * inconsistencies in this calculation (for e.g., for 52-bit
++ * kernel VA case, the 48th bit is set in * the _stext symbol).
++ */
++ if ((_stext & PAGE_OFFSET_48) == PAGE_OFFSET_48) {
++ va_bits = 48;
++ } else if ((_stext & PAGE_OFFSET_47) == PAGE_OFFSET_47) {
++ va_bits = 47;
++ } else if ((_stext & PAGE_OFFSET_42) == PAGE_OFFSET_42) {
++ va_bits = 42;
++ } else if ((_stext & PAGE_OFFSET_39) == PAGE_OFFSET_39) {
++ va_bits = 39;
++ } else if ((_stext & PAGE_OFFSET_36) == PAGE_OFFSET_36) {
++ va_bits = 36;
++ } else {
++ ERRMSG("Cannot find a proper _stext for calculating VA_BITS\n");
++ return FALSE;
++ }
++
++ DEBUG_MSG("va_bits : %d (guess from _stext)\n", va_bits);
++
++ return TRUE;
++}
++
+ int
+ get_machdep_info_arm64(void)
+ {
+@@ -398,27 +435,11 @@ get_xen_info_arm64(void)
+ int
+ get_versiondep_info_arm64(void)
+ {
+- ulong _stext;
+-
+- _stext = get_stext_symbol();
+- if (!_stext) {
+- ERRMSG("Can't get the symbol of _stext.\n");
+- return FALSE;
+- }
+-
+- /* Derive va_bits as per arch/arm64/Kconfig */
+- if ((_stext & PAGE_OFFSET_36) == PAGE_OFFSET_36) {
+- va_bits = 36;
+- } else if ((_stext & PAGE_OFFSET_39) == PAGE_OFFSET_39) {
+- va_bits = 39;
+- } else if ((_stext & PAGE_OFFSET_42) == PAGE_OFFSET_42) {
+- va_bits = 42;
+- } else if ((_stext & PAGE_OFFSET_47) == PAGE_OFFSET_47) {
+- va_bits = 47;
+- } else if ((_stext & PAGE_OFFSET_48) == PAGE_OFFSET_48) {
+- va_bits = 48;
+- } else {
+- ERRMSG("Cannot find a proper _stext for calculating VA_BITS\n");
++ if (NUMBER(VA_BITS) != NOT_FOUND_NUMBER) {
++ va_bits = NUMBER(VA_BITS);
++ DEBUG_MSG("va_bits : %d (vmcoreinfo)\n", va_bits);
++ } else if (get_va_bits_from_stext_arm64() == FALSE) {
++ ERRMSG("Can't determine va_bits.\n");
+ return FALSE;
+ }
+
+--
+2.29.2
+
diff --git a/kexec-tools-2.0.21-makedumpfile-PATCH-3-3-arm64-support-flipped-VA-and-52-bit-kernel.patch b/kexec-tools-2.0.21-makedumpfile-PATCH-3-3-arm64-support-flipped-VA-and-52-bit-kernel.patch
new file mode 100644
index 0000000..752bb07
--- /dev/null
+++ b/kexec-tools-2.0.21-makedumpfile-PATCH-3-3-arm64-support-flipped-VA-and-52-bit-kernel.patch
@@ -0,0 +1,245 @@
+From a0216b678a95f099a16172cc4a67ad5aa6a89583 Mon Sep 17 00:00:00 2001
+From: Kazuhito Hagio <k-hagio-ab(a)nec.com>
+Date: Fri, 29 Jan 2021 11:40:25 +0900
+Subject: [PATCH 3/3] [PATCH 3/3] arm64: support flipped VA and 52-bit kernel
+ VA
+
+Linux 5.4 and later kernels for arm64 changed the kernel VA space
+arrangement and introduced 52-bit kernel VAs by merging branch
+commit b333b0ba2346. Support 5.9+ kernels with vmcoreinfo entries
+and 5.4+ kernels with best guessing.
+
+However, the following conditions are not supported for now due to
+no necessary information provided from kernel:
+(1) 5.4 <= kernels <= 5.8 and
+ - if PA_BITS=52 && VA_BITS!=52
+ - with -x option if vabits_actual=52
+(2) kernels < 5.4 with CONFIG_ARM64_USER_VA_BITS_52=y
+
+(1) should be supported with kernel commit bbdbc11804ff and
+1d50e5d0c5052 adding necessary information to vmcoreinfo.
+
+Signed-off-by: Bhupesh Sharma <bhsharma(a)redhat.com>
+Signed-off-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
+Reviewed-by: Pingfan Liu <piliu(a)redhat.com>
+---
+ arch/arm64.c | 100 +++++++++++++++++++++++++++++++++++++++++--------
+ makedumpfile.c | 2 +
+ makedumpfile.h | 1 +
+ 3 files changed, 88 insertions(+), 15 deletions(-)
+
+diff --git a/makedumpfile-1.6.8/arch/arm64.c b/makedumpfile-1.6.8/arch/arm64.c
+index 2916b4f..1072178 100644
+--- a/makedumpfile-1.6.8/arch/arm64.c
++++ b/makedumpfile-1.6.8/arch/arm64.c
+@@ -47,6 +47,8 @@ typedef struct {
+ static int lpa_52_bit_support_available;
+ static int pgtable_level;
+ static int va_bits;
++static int vabits_actual;
++static int flipped_va;
+ static unsigned long kimage_voffset;
+
+ #define SZ_4K 4096
+@@ -58,7 +60,6 @@ static unsigned long kimage_voffset;
+ #define PAGE_OFFSET_42 ((0xffffffffffffffffUL) << 42)
+ #define PAGE_OFFSET_47 ((0xffffffffffffffffUL) << 47)
+ #define PAGE_OFFSET_48 ((0xffffffffffffffffUL) << 48)
+-#define PAGE_OFFSET_52 ((0xffffffffffffffffUL) << 52)
+
+ #define pgd_val(x) ((x).pgd)
+ #define pud_val(x) (pgd_val((x).pgd))
+@@ -218,12 +219,20 @@ pmd_page_paddr(pmd_t pmd)
+ #define pte_index(vaddr) (((vaddr) >> PAGESHIFT()) & (PTRS_PER_PTE - 1))
+ #define pte_offset(dir, vaddr) (pmd_page_paddr((*dir)) + pte_index(vaddr) * sizeof(pte_t))
+
++/*
++ * The linear kernel range starts at the bottom of the virtual address
++ * space. Testing the top bit for the start of the region is a
++ * sufficient check and avoids having to worry about the tag.
++ */
++#define is_linear_addr(addr) (flipped_va ? \
++ (!((unsigned long)(addr) & (1UL << (vabits_actual - 1)))) : \
++ (!!((unsigned long)(addr) & (1UL << (vabits_actual - 1)))))
++
+ static unsigned long long
+ __pa(unsigned long vaddr)
+ {
+- if (kimage_voffset == NOT_FOUND_NUMBER ||
+- (vaddr >= PAGE_OFFSET))
+- return (vaddr - PAGE_OFFSET + info->phys_base);
++ if (kimage_voffset == NOT_FOUND_NUMBER || is_linear_addr(vaddr))
++ return ((vaddr & ~PAGE_OFFSET) + info->phys_base);
+ else
+ return (vaddr - kimage_voffset);
+ }
+@@ -253,6 +262,7 @@ static int calculate_plat_config(void)
+ (PAGESIZE() == SZ_64K && va_bits == 42)) {
+ pgtable_level = 2;
+ } else if ((PAGESIZE() == SZ_64K && va_bits == 48) ||
++ (PAGESIZE() == SZ_64K && va_bits == 52) ||
+ (PAGESIZE() == SZ_4K && va_bits == 39) ||
+ (PAGESIZE() == SZ_16K && va_bits == 47)) {
+ pgtable_level = 3;
+@@ -263,6 +273,7 @@ static int calculate_plat_config(void)
+ PAGESIZE(), va_bits);
+ return FALSE;
+ }
++ DEBUG_MSG("pgtable_level: %d\n", pgtable_level);
+
+ return TRUE;
+ }
+@@ -270,6 +281,9 @@ static int calculate_plat_config(void)
+ unsigned long
+ get_kvbase_arm64(void)
+ {
++ if (flipped_va)
++ return PAGE_OFFSET;
++
+ return (0xffffffffffffffffUL << va_bits);
+ }
+
+@@ -382,22 +396,54 @@ get_va_bits_from_stext_arm64(void)
+ return TRUE;
+ }
+
++static void
++get_page_offset_arm64(void)
++{
++ ulong page_end;
++ int vabits_min;
++
++ /*
++ * See arch/arm64/include/asm/memory.h for more details of
++ * the PAGE_OFFSET calculation.
++ */
++ vabits_min = (va_bits > 48) ? 48 : va_bits;
++ page_end = -(1UL << (vabits_min - 1));
++
++ if (SYMBOL(_stext) > page_end) {
++ flipped_va = TRUE;
++ info->page_offset = -(1UL << vabits_actual);
++ } else {
++ flipped_va = FALSE;
++ info->page_offset = -(1UL << (vabits_actual - 1));
++ }
++
++ DEBUG_MSG("page_offset : %lx (from page_end check)\n",
++ info->page_offset);
++}
++
+ int
+ get_machdep_info_arm64(void)
+ {
++ /* Check if va_bits is still not initialized. If still 0, call
++ * get_versiondep_info() to initialize the same.
++ */
++ if (!va_bits)
++ get_versiondep_info_arm64();
++
+ /* Determine if the PA address range is 52-bits: ARMv8.2-LPA */
+ if (NUMBER(MAX_PHYSMEM_BITS) != NOT_FOUND_NUMBER) {
+ info->max_physmem_bits = NUMBER(MAX_PHYSMEM_BITS);
++ DEBUG_MSG("max_physmem_bits : %ld (vmcoreinfo)\n", info->max_physmem_bits);
+ if (info->max_physmem_bits == 52)
+ lpa_52_bit_support_available = 1;
+- } else
+- info->max_physmem_bits = 48;
++ } else {
++ if (va_bits == 52)
++ info->max_physmem_bits = 52; /* just guess */
++ else
++ info->max_physmem_bits = 48;
+
+- /* Check if va_bits is still not initialized. If still 0, call
+- * get_versiondep_info() to initialize the same.
+- */
+- if (!va_bits)
+- get_versiondep_info_arm64();
++ DEBUG_MSG("max_physmem_bits : %ld (guess)\n", info->max_physmem_bits);
++ }
+
+ if (!calculate_plat_config()) {
+ ERRMSG("Can't determine platform config values\n");
+@@ -408,7 +454,6 @@ get_machdep_info_arm64(void)
+ info->section_size_bits = SECTIONS_SIZE_BITS;
+
+ DEBUG_MSG("kimage_voffset : %lx\n", kimage_voffset);
+- DEBUG_MSG("max_physmem_bits : %ld\n", info->max_physmem_bits);
+ DEBUG_MSG("section_size_bits: %ld\n", info->section_size_bits);
+
+ return TRUE;
+@@ -443,10 +488,35 @@ get_versiondep_info_arm64(void)
+ return FALSE;
+ }
+
+- info->page_offset = (0xffffffffffffffffUL) << (va_bits - 1);
++ /*
++ * See TCR_EL1, Translation Control Register (EL1) register
++ * description in the ARMv8 Architecture Reference Manual.
++ * Basically, we can use the TCR_EL1.T1SZ value to determine
++ * the virtual addressing range supported in the kernel-space
++ * (i.e. vabits_actual) since Linux 5.9.
++ */
++ if (NUMBER(TCR_EL1_T1SZ) != NOT_FOUND_NUMBER) {
++ vabits_actual = 64 - NUMBER(TCR_EL1_T1SZ);
++ DEBUG_MSG("vabits_actual : %d (vmcoreinfo)\n", vabits_actual);
++ } else if ((va_bits == 52) && (SYMBOL(mem_section) != NOT_FOUND_SYMBOL)) {
++ /*
++ * Linux 5.4 through 5.10 have the following linear space:
++ * 48-bit: 0xffff000000000000 - 0xffff7fffffffffff
++ * 52-bit: 0xfff0000000000000 - 0xfff7ffffffffffff
++ * and SYMBOL(mem_section) should be in linear space if
++ * the kernel is configured with COMFIG_SPARSEMEM_EXTREME=y.
++ */
++ if (SYMBOL(mem_section) & (1UL << (va_bits - 1)))
++ vabits_actual = 48;
++ else
++ vabits_actual = 52;
++ DEBUG_MSG("vabits_actual : %d (guess from mem_section)\n", vabits_actual);
++ } else {
++ vabits_actual = va_bits;
++ DEBUG_MSG("vabits_actual : %d (same as va_bits)\n", vabits_actual);
++ }
+
+- DEBUG_MSG("va_bits : %d\n", va_bits);
+- DEBUG_MSG("page_offset : %lx\n", info->page_offset);
++ get_page_offset_arm64();
+
+ return TRUE;
+ }
+diff --git a/makedumpfile-1.6.8/makedumpfile.c b/makedumpfile-1.6.8/makedumpfile.c
+index 768eda4..fcd766b 100644
+--- a/makedumpfile-1.6.8/makedumpfile.c
++++ b/makedumpfile-1.6.8/makedumpfile.c
+@@ -2397,6 +2397,7 @@ write_vmcoreinfo_data(void)
+ WRITE_NUMBER("HUGETLB_PAGE_DTOR", HUGETLB_PAGE_DTOR);
+ #ifdef __aarch64__
+ WRITE_NUMBER("VA_BITS", VA_BITS);
++ /* WRITE_NUMBER("TCR_EL1_T1SZ", TCR_EL1_T1SZ); should not exists */
+ WRITE_NUMBER_UNSIGNED("PHYS_OFFSET", PHYS_OFFSET);
+ WRITE_NUMBER_UNSIGNED("kimage_voffset", kimage_voffset);
+ #endif
+@@ -2836,6 +2837,7 @@ read_vmcoreinfo(void)
+ READ_NUMBER("KERNEL_IMAGE_SIZE", KERNEL_IMAGE_SIZE);
+ #ifdef __aarch64__
+ READ_NUMBER("VA_BITS", VA_BITS);
++ READ_NUMBER("TCR_EL1_T1SZ", TCR_EL1_T1SZ);
+ READ_NUMBER_UNSIGNED("PHYS_OFFSET", PHYS_OFFSET);
+ READ_NUMBER_UNSIGNED("kimage_voffset", kimage_voffset);
+ #endif
+diff --git a/makedumpfile-1.6.8/makedumpfile.h b/makedumpfile-1.6.8/makedumpfile.h
+index 0ed6417..97a5554 100644
+--- a/makedumpfile-1.6.8/makedumpfile.h
++++ b/makedumpfile-1.6.8/makedumpfile.h
+@@ -2049,6 +2049,7 @@ struct number_table {
+ long KERNEL_IMAGE_SIZE;
+ #ifdef __aarch64__
+ long VA_BITS;
++ long TCR_EL1_T1SZ;
+ unsigned long PHYS_OFFSET;
+ unsigned long kimage_voffset;
+ #endif
+--
+2.29.2
+
diff --git a/kexec-tools.spec b/kexec-tools.spec
index 69a89d5..0da4382 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -96,6 +96,10 @@ Requires: systemd-udev%{?_isa}
#
# Patches 501 through 600 are meant for ARM kexec-tools enablement
#
+Patch501: ./kexec-tools-2.0.21-makedumpfile-PATCH-1-3-Use-vmcoreinfo-note-in-proc-kcore-for-mem-.patch
+Patch502: ./kexec-tools-2.0.21-makedumpfile-PATCH-2-3-arm64-Make-use-of-NUMBER-VA_BITS-in-vmcore.patch
+Patch503: ./kexec-tools-2.0.21-makedumpfile-PATCH-3-3-arm64-support-flipped-VA-and-52-bit-kernel.patch
+
#
# Patches 601 onward are generic patches
@@ -121,6 +125,9 @@ mkdir -p -m755 kcp
tar -z -x -v -f %{SOURCE9}
tar -z -x -v -f %{SOURCE19}
+%patch501 -p1
+%patch502 -p1
+%patch503 -p1
%patch603 -p1
%patch604 -p1
%patch605 -p1
--
2.29.2
2 years, 7 months
[PATCH 0/3] Makedumpfile gets estimated vmcore size with specified options
by Tao Liu
This patch set backport patches from makedumpfile upstream, which provide
dry-run and show-stats options, to help estimate if there is enough free
space to save the vmcore in a target.
Tao Liu (3):
Add --dry-run option to prevent writing the dumpfile
Add shorthand --show-stats option to show report stats
Show write byte size in report messages
...0.21-makedumpfile-Add-dry-run-option.patch | 177 ++++++++++++++++++
...file-Add-shorthand-show-stats-option.patch | 107 +++++++++++
...w-write-byte-size-in-report-messages.patch | 59 ++++++
kexec-tools.spec | 6 +
4 files changed, 349 insertions(+)
create mode 100644 kexec-tools-2.0.21-makedumpfile-Add-dry-run-option.patch
create mode 100644 kexec-tools-2.0.21-makedumpfile-Add-shorthand-show-stats-option.patch
create mode 100644 kexec-tools-2.0.21-makedumpfile-Show-write-byte-size-in-report-messages.patch
--
2.29.2
2 years, 7 months
[PATCH] Make dracut-squash required for kexec-tools
by Tao Liu
This patch reverts commit "Make dracut-squash a weak dep".
Although kexec-tools can work without dracut-squash, it is essential
for kdump to run properly in cases [1][2] where minimal amount of memory
consumption is expected. Thus dracut-squash is needed for it.
[1] https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.o...
[2] https://www.spinics.net/lists/systemd-devel/msg05864.html
Signed-off-by: Tao Liu <ltao(a)redhat.com>
---
dracut-module-setup.sh | 3 ---
kexec-tools.spec | 2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index 21143b4..3a1cc2f 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -35,9 +35,6 @@ depends() {
modprobe -S $KDUMP_KERNELVER --dry-run $kmodule &>/dev/null || return 1
fi
done
-
- # check that the dracut squash module is available
- [ -d "$(dracut_module_path squash)" ] || return 1
}
if is_squash_available && ! is_fadump_capable; then
diff --git a/kexec-tools.spec b/kexec-tools.spec
index 88ba2bd..7a9949d 100644
--- a/kexec-tools.spec
+++ b/kexec-tools.spec
@@ -61,7 +61,7 @@ Requires(postun): systemd-units
Requires(pre): coreutils sed zlib
Requires: dracut >= 050
Requires: dracut-network >= 050
-Recommends: dracut-squash >= 050
+Requires: dracut-squash >= 050
Requires: ethtool
Requires: ipcalc
BuildRequires: make
--
2.29.2
2 years, 7 months
[PATCH v4 0/3] Use a standalone kdump emergency shell
by Kairui Song
Currently kdump use some wrapper around dracut emergency service and
emergency shell, this have many problems:
- If dracut-initqueue failed back to emergency mode due to timeout,
and faiure action is set to dump_to_rootfs, kdump will try start
initqueue again, lead to double timeout error.
- Dracut's emergency shell have many builtin actions, like
perform dracut emergency_action, ask for root password, generate
rdsosreport etc.
This series remove the emergency wrapper, and use a standalone kdump
emergency shell. Kdump will always perform final_action after kdump
shell, so simplified version works fine.
Update from V3:
- Fix initqueue dead loop in patch 1/3 found by Coiby.
Checking is-active || is-failure is not valid here since initqueue
might stuck in activating status, so check service status instead.
Update from V2:
Fix an redundant string escaping issue found by Coiby.
Update from V1:
Fix initqueue status detection in patch 1/3, thanks to Coiby.
Kairui Song (3):
Don's try to restart dracut-initqueue if it's already there
Remove the kdump error handler isolation wrapper
Use a customized emergency shell
dracut-kdump-emergency.service | 25 +++++++++----------
dracut-kdump-error-handler.service | 33 ------------------------
dracut-module-setup.sh | 1 -
kdump-lib-initramfs.sh | 40 +++++++++++++++++++++++++-----
kexec-tools.spec | 2 --
5 files changed, 46 insertions(+), 55 deletions(-)
delete mode 100644 dracut-kdump-error-handler.service
--
2.30.2
2 years, 7 months
[PATCH v3 0/3] Use a standalone kdump emergency shell
by Kairui Song
Currently kdump use some wrapper around dracut emergency service and
emergency shell, this have many problems:
- If dracut-initqueue failed back to emergency mode due to timeout,
and faiure action is set to dump_to_rootfs, kdump will try start
initqueue again, lead to double timeout error.
- Dracut's emergency shell have many builtin actions, like
perform dracut emergency_action, ask for root password, generate
rdsosreport etc.
This series remove the emergency wrapper, and use a standalone kdump
emergency shell. Kdump will always perform final_action after kdump
shell, so simplified version works fine.
Update from V2:
Fix an redundant string escaping issue found by Coiby.
Update from V1:
Fix initqueue status detection in patch 1/3, thanks to Coiby.
Kairui Song (3):
Don's try to restart dracut-initqueue if it's already there
Remove the kdump error handler isolation wrapper
Use a customized emergency shell
dracut-kdump-emergency.service | 25 +++++++++----------
dracut-kdump-error-handler.service | 33 ------------------------
dracut-module-setup.sh | 1 -
kdump-lib-initramfs.sh | 40 +++++++++++++++++++++++++-----
kexec-tools.spec | 2 --
5 files changed, 46 insertions(+), 55 deletions(-)
delete mode 100644 dracut-kdump-error-handler.service
--
2.30.2
2 years, 7 months