Resolves: bz2219378
Upstream: RHEL-ONLY
Conflict: None
The commit 68d02c2a casused a regression that mount sysroot will fail in
the kdump kernel. Since that commit only fixed a print issue, revert it.
This issue is related to a systemd bug which has been fixed by this PR:
https://github.com/systemd/systemd/pull/23893, before these patches are
backported to RHEL-8, we should keep the nofail and x-systemd.before
options.
Fixes: 68d02c2a
(Revert "Append both nofail and x-systemd.before to kdump mount target")
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: bz1958587
Upstream: Fedora
Conflict: None
commit 3b22cce1cb
Author: Coiby Xu <coxu@redhat.com>
Date: Wed Dec 14 10:12:17 2022 +0800
dracut-module-setup.sh: skip installing driver for the loopback
interface
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2151500
Currently, kdump initrd fails to be built when dumping vmcore to
localhost via ssh or nfs,
kdumpctl[3331]: Cannot get driver information: Operation not supported
kdumpctl[1991]: dracut: Failed to get the driver of lo
dracut[2020]: Failed to get the driver of lo
kdumpctl[1775]: kdump: mkdumprd: failed to make kdump initrd
kdumpctl[1775]: kdump: Starting kdump: [FAILED]
systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: kdump.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Crash recovery kernel arming.
systemd[1]: kdump.service: Consumed 1.710s CPU time.
This is because the loopback interface is used for transferring vmcore and
ethtool can't get the driver of the loopback interface. In fact, once
COFNIG_NET is enabled, the loopback device is enabled and there is no driver
for the loopback device. So skip installing driver for the loopback device.
The loopback interface is implemented in linux/drivers/net/loopback.c
and always has the name "lo". So we can safely tell if a network
interface is the loopback interface by its name.
Fixes: a65dde2d ("Reduce kdump memory consumption by only installing needed NIC drivers")
Reported-by: Martin Pitt <mpitt@redhat.com>
Reported-by: Rich Megginson <rmeggins@redhat.com>
Reviewed-by: Lichen Liu <lichliu@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz1958587
Upstream: Fedora
Conflict: 1. RHEL8's mkdumprd has different dracut_args from upstream's.
2. RHEL8's kdump_install_net is different from upstream's and
we should install needed NIC drivers in the end.
commit a65dde2d10
Author: Coiby Xu <coxu@redhat.com>
Date: Thu May 19 11:39:25 2022 +0800
Reduce kdump memory consumption by only installing needed NIC drivers
Even after having asked NM to stop managing a unneeded NIC, a NIC driver
may still waste memory. For example, mlx5_core uses a substantial amount
of memory during driver initialization,
======== Report format module_summary: ========
Module mlx5_core using 350.2MB (89650 pages), peak allocation 367.4MB (94056 pages)
Module squashfs using 13.1MB (3360 pages), peak allocation 13.1MB (3360 pages)
Module overlay using 2.1MB (550 pages), peak allocation 2.2MB (555 pages)
Module dns_resolver using 0.9MB (219 pages), peak allocation 5.2MB (1338 pages)
Module mlxfw using 0.7MB (172 pages), peak allocation 5.3MB (1349 pages)
======== Report format module_summary END ========
======== Report format module_top: ========
Top stack usage of module mlx5_core:
(null) Pages: 89650 (peak: 94056)
ret_from_fork (0xffffda088b4165f8) Pages: 60007 (peak: 60007)
kthread (0xffffda088b4bd7e4) Pages: 60007 (peak: 60007)
worker_thread (0xffffda088b4b48d0) Pages: 60007 (peak: 60007)
process_one_work (0xffffda088b4b3f40) Pages: 60007 (peak: 60007)
work_for_cpu_fn (0xffffda088b4aef00) Pages: 53906 (peak: 53906)
local_pci_probe (0xffffda088b9e1e44) Pages: 53906 (peak: 53906)
probe_one mlx5_core (0xffffda084f899cc8) Pages: 53518 (peak: 53518)
mlx5_init_one mlx5_core (0xffffda084f8994ac) Pages: 49756 (peak: 49756)
mlx5_function_setup.constprop.0 mlx5_core (0xffffda084f899100) Pages: 44434 (eak: 44434)
mlx5_satisfy_startup_pages mlx5_core (0xffffda084f8a4f24) Pages: 44434 (peak: 44434)
mlx5_function_setup.constprop.0 mlx5_core (0xffffda084f899078) Pages: 5285 (peak: 5285)
mlx5_cmd_init mlx5_core (0xffffda084f89e414) Pages: 4818 (peak: 4818)
mlx5_alloc_cmd_msg mlx5_core (0xffffda084f89aaa0) Pages: 4403 (peak: 4403)
This memory consumption is completely unnecessary when kdump doesn't need
this NIC. Only install needed NIC drivers to prevent this kind of waste.
Note
1. this patch depends on [1] to ask dracut to not install NIC drivers.
2. "ethtool -i" somehow fails to get the vlan driver
3. team.ko doesn't depend on the team mode drivers so we need to install
the team mode drivers manually.
[1] https://github.com/dracutdevs/dracut/pull/1789
Signed-off-by: Coiby Xu <coxu@redhat.com>
Reviewed-by: Thomas Haller <thaller@redhat.com>
Reviewed-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: bz2164929
Upstream: Fedora
Conflict: Missing upstream commit
94a7b4("Always drop nofail or nobootwait options")
commit 0843c70672
Author: Kairui Song <kasong@redhat.com>
Date: Wed Jan 13 17:12:18 2021 +0800
Revert "Append both nofail and x-systemd.before to kdump mount target"
That commit is trying to workaround a kernel VFS bug. Now,
the VFS issue should have been fixed in all recent releases, so
remove this workaround.
This reverts commit 539bff4083.
Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
Signed-off-by: Lichen Liu <lichliu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1964822
Upstream: RHEL-only
Currently, vmcore dumping to remote fs gives a warning "eth0: Failed to
rename network interface 3 from 'eth0' to 'kdump-eth0': File exists" on
Azure Hyper-V VM with accelerated networking because it uses a physical
NIC for accelerated networking [1] and the backing physical NIC has the
same MAC address as the virtual NIC. In the kdump initrd, an udev rule
will try renaming NICs with the given MAC address and fails as expected
since there are two NICs having the same MAC address. This udev rule is
created automatically when specifying the dracut cmdline
"ifname=<interface>:<MAC>". For the case of Azure Hyper-V VM with
accelerated networking, only the virtual network interface need to be
renamed. So create an udev rule manually.
[1] https://learn.microsoft.com/en-us/azure/virtual-network/accelerated-networking-overview
Signed-off-by: Coiby Xu <coxu@redhat.com>
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1964822
Upstream: RHEL-only
Currently, vmcore dumping to remote fs gives a warning "eth0: Failed to
rename network interface 3 from 'eth0' to 'kdump-eth0': File exists" on
Azure Hyper-V VM with accelerated networking because it uses a physical
NIC for accelerated networking [1] and the backing physical NIC has the
same MAC as the virtual NIC. There is no need to rename a Hypver-V
interface in this case which also leads the aforementioned warning.
[1] https://learn.microsoft.com/en-us/azure/virtual-network/accelerated-networking-overview
Signed-off-by: Coiby Xu <coxu@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2184284
Resolves: rhbz#2184284
Upstream: makedumpfile
commit 58553ad03187f0cf208d6c4a0dc026c6338e5edd
Author: Daisuke Hatayama (Fujitsu) <d.hatayama@fujitsu.com>
Date: Wed Mar 29 12:44:10 2023 +0000
[PATCH] sadump: fix failure of reading memory when 5-level paging is enabled
makedumpfile fails as follows for memory dumps collected by sadump
when 5-level paging is enabled on the corresponding systems:
# makedumpfile -l -d 31 -x ./vmlinux ./dump.sadump dump.sadump-ld31
__vtop4_x86_64: Can't get a valid pgd.
...snip...
__vtop4_x86_64: Can't get a valid pgd.
calc_kaslr_offset: failed to calculate kaslr_offset and phys_base; default to 0
__vtop4_x86_64: Can't get a valid pgd.
readmem: Can't convert a virtual address(ffffffff82fce960) to physical address.
readmem: type_addr: 0, addr:ffffffff82fce960, size:1024
cpu_online_mask_init: Can't read cpu_online_mask memory.
makedumpfile Failed.
This is because 5-level paging support has not been done yet for
sadump; the work of the 5-level paging support was done by the commit
30a3214a7193e94c551c0cebda5918a72a35c589 (PATCH 4/4 arch/x86_64: Add
5-level paging support) but that was focused on the core part only.
Having said that, most of things has already been finished in the
commit. What needs to be newly added for sadump is just how to check
if 5-level paging is enabled for a given memory dump.
For that purpose, let's refer to CR4.LA57, bit 12 of CR4, representing
whether 5-level paging is enabled or not. We can do this because
memory dumps collected by sadump have SMRAM as note information and
they include CR4 together with the other control registers.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@fujitsu.com>
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Resolves: bz2149846
Upstream: Fedora
Conflict: Move to kdump.sysconfig.s390 due to missing
677da8a ("sysconfig: use a simple generator script to maintain")
Author: Philipp Rudo <prudo@redhat.com>
Date: Tue Mar 7 14:45:35 2023 +0100
sysconfig: add zfcp.allow_lun_scan to KDUMP_COMMANDLINE_REMOVE on s390
Probing unnecessary I/O devices wastes memory and in extreme cases can
cause the crashkernel to run OOM. That's why the s390-tools maintain
their own module, 95zdev-kdump [1], that disables auto LUN scanning and
only configures zfcp devices that can be used as dump target. So remove
zfcp.allow_lun_scan from the kernel command line to prevent that we
accidentally overwrite the default set by the module.
[1] https://github.com/ibm-s390-linux/s390-tools/blob/master/zdev/dracut/95zdev-kdump/module-setup.sh
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Reviewed-by: Coiby Xu <coxu@redhat.com>
Signed-off-by: Philipp Rudo <prudo@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
