Commit Graph

25 Commits

Author SHA1 Message Date
Lianbo Jiang
e5cbf4d1ad x86_64: enable the kexec file load by default
Let's use the option KEXEC_ARGS="-s" to enable the kexec file load
by default.

Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2020-07-01 17:07:46 +08:00
Lianbo Jiang
073646998f Revert "kdump-lib: switch to the kexec_file_load() syscall on x86_64 by default"
This reverts commit 6a20bd5447.

Let's restore the logic of secureboot status check, and remove the
option 'KDUMP_FILE_LOAD=on|off'. We will use the option KEXEC_ARGS="-s"
to enable the kexec file load later, which can avoid failures when
the secureboot is enabled.

Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2020-07-01 17:07:46 +08:00
Kairui Song
134c578463 Don't inherit swiotlb parameter form 1st kernel by default
Usually kdump kernel don't need a swiotlb. There are two cases known
common case a swiotlb is needed:

 - SEV/SME is active.
 - crashkernel high reservation is used, or there are crashkernel memory
   above 4G.

For both case, if swiotlb is set to a large value in first kernel, kdump
kernel will likely to fail with OOM. So don't inherit swiotlb parameter
by default.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
2020-05-29 10:56:31 +08:00
Lianbo Jiang
a81ec90ed8 kdump.sysconfig: Remove the option 'log_buf_len' from kdump command line
The option 'log_buf_len' in the kernel command line will make kernel
dynamically allocate memory (system ram) from memblock and always hold
the memory allocated. If the size of this option is misused such as
'log_buf_len=64M'. This may cause a short of memory for kdump kernel,
because the size of memory is usually limited in kdump kernel.

In order to avoid this problem, need to remove this option from the
kdump kernel command line.

Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Pingfan Liu <piliu@redhat.com>
2020-05-28 10:11:15 +08:00
Lianbo Jiang
6a20bd5447 kdump-lib: switch to the kexec_file_load() syscall on x86_64 by default
UEFI Secure boot is a signature verification mechanism, designed to
prevent malicious code being loaded and executed at the early boot
stage. This makes sure that code executed is trusted by firmware.

Previously, with kexec_file_load() interface, kernel prevents unsigned
kernel image from being loaded if secure boot is enabled. So kdump will
detect whether secure boot is enabled firstly, then decide which interface
is chosen to execute, kexec_load() or kexec_file_load(). Otherwise unsigned
kernel loading will fail if secure boot enabled, and kexec_file_load() is
entered.

Now, the implementation of kexec_file_load() is adjusted in below commit.
With this change, if CONFIG_KEXEC_SIG_FORCE is not set, unsigned kernel
still has a chance to be allowed to load under some conditions.

commit 99d5cadfde2b ("kexec_file: split KEXEC_VERIFY_SIG into KEXEC_SIG
and KEXEC_SIG_FORCE")

And in the current Fedora, the CONFIG_KEXEC_SIG_FORCE is not set, only the
CONFIG_KEXEC_SIG and CONFIG_BZIMAGE_VERIFY_SIG are set on x86_64 by default.
It's time to spread kexec_file_load() onto all systems of x86_64, including
Secure-boot platforms and legacy platforms. Please refer to the following
form.

.----------------------------------------------------------------------.
| .                    |     signed kernel     |    unsigned kernel    |
|    .      types      |-----------------------|-----------------------|
|       .              |Secure boot|  Legacy   |Secure boot|  Legacy   |
|          .           |-----------|-----------|-----------|-----------|
| options     .        | prev| now | prev| now |     |     | prev| now |
|                .     |(file|(file|(only|(file| prev| now |(only|(file|
|                    . |load)|load)|load)|load)|     |     |load)|load)|
|----------------------|-----|-----|-----|-----|-----|-----|-----|-----|
|KEXEC_SIG=y           |     |     |     |     |     |     |     |     |
|SIG_FORCE is not set  |succ |succ |succ |succ |  X  |  X  |succ |succ |
|BZIMAGE_VERIFY_SIG=y  |     |     |     |     |     |     |     |     |
|----------------------|-----|-----|-----|-----|-----|-----|-----|-----|
|KEXEC_SIG=y           |     |     |     |     |     |     |     |     |
|SIG_FORCE is not set  |     |     |     |     |     |     |     |     |
|BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail |  X  |  X  |succ |fail |
|not set               |     |     |     |     |     |     |     |     |
|----------------------|-----|-----|-----|-----|-----|-----|-----|-----|
|KEXEC_SIG=y           |     |     |     |     |     |     |     |     |
|SIG_FORCE=y           |succ |succ |succ |fail |  X  |  X  |succ |fail |
|BZIMAGE_VERIFY_SIG=y  |     |     |     |     |     |     |     |     |
|----------------------|-----|-----|-----|-----|-----|-----|-----|-----|
|KEXEC_SIG=y           |     |     |     |     |     |     |     |     |
|SIG_FORCE=y           |     |     |     |     |     |     |     |     |
|BZIMAGE_VERIFY_SIG is |fail |fail |succ |fail |  X  |  X  |succ |fail |
|not set               |     |     |     |     |     |     |     |     |
|----------------------|-----|-----|-----|-----|-----|-----|-----|-----|
|KEXEC_SIG is not set  |     |     |     |     |     |     |     |     |
|SIG_FORCE is not set  |     |     |     |     |     |     |     |     |
|BZIMAGE_VERIFY_SIG is |fail |fail |succ |succ |  X  |  X  |succ |succ |
|not set               |     |     |     |     |     |     |     |     |
 ----------------------------------------------------------------------
Note:
[1] The 'X' indicates that the 1st kernel(unsigned) can not boot when the
    Secure boot is enabled.

Hence, in this patch, if on x86_64, let's use the kexec_file_load() only.
See if anything wrong happened in this case, in Fedora firstly for the
time being.

Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Acked-by: Kairui Song <kasong@redhat.com>
2020-02-06 21:57:14 +08:00
Kairui Song
ff329689b3 Disable device dump by default
Device dump may use a log of memory and cause OOM issue, so append
"novmcoredd" option for second kernel and disable it by default.
To use device dump, user should remove the vmcoredd parameter
manually.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-09-02 17:06:09 +08:00
Kairui Song
b998b90197 kdump.sysconfig/x86_64: Disable HEST by default
Some firmware will provide a ACPI HEST table with massive amount of
entries, and the way how kernel handles these entries will consume a lot
of memory which will lead to OOM issue in kdump kernel. During testing
on certain machine, disable HEST saved ~60M of memory.

Kdump is only for emergency use in case of a kernel panic, so temporarily
disable hardware error report & recovery related feature is acceptable
in general. So disable HEST support in kdump kernel to save memory.

Currently such issue is only observed on x86_64, so limit this change to
x86_64 only.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2019-07-09 14:11:36 +08:00
Kairui Song
94a7b43407 Always drop nofail or nobootwait options
If nofail or nobootwait option is used, systemd's local-fs.target won't
wait for the mounting to complete, and kdump might start before the
required mount point is ready and then fail.

The host might use nofail for reasons like the device may get unpluged,
and if the device is not mounted and it is set as kdump target as the same
time then kdump service won't start, we will never enter the capture
kernel. By the time we have entered the capture kernel, the target device
must exist and ready to use, or else kdump would fail anyway. So force
remove nofail and nobootwait option.

Also drop rootflags=nofail option, as we don't depend on rootfs anymore
if the dump target don't required it. So the nofail option is no longer
needed.

Signed-off-by: Kairui Song <kasong@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2018-08-14 10:34:45 +08:00
Baoquan He
c3602e32a2 kdump.sysconfig/x86_64: Add nokaslr to kdump kernel cmdline
KASLR is to enhance security on OS kernel. While kdump kernel is
working after normal kernel corrupted. There's no need to do kaslr
in kdump kernel, so add 'nokaslr' to disable kaslr.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2017-04-27 13:59:49 +08:00
Dave Young
53564adc08 Remove kernel param "quiet" from kdump kernel cmdline
"quiet" will disable most of log messages. For debugging kdump
kernel purpose it is better to remove quiet in 2nd kernel so that
we always see kernel messages.

Signed-off-by: Dangyi Liu <dliu@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2015-12-11 15:18:31 +08:00
Dangyi Liu
3ec336c06c kdump.sysconfig: add KDUMP_COMMANDLINE_REMOVE
Use KDUMP_COMMANDLINE_REMOVE config instead of hardcode them in
kdumpctl, which makes it possible system admins decide what params to
remove such as "quiet" or other debug flags.

This patch also adds backward compatibility even if an old config is
used. It will behave the same as the old version.

Signed-off-by: Dangyi Liu <dliu@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2015-12-11 15:16:35 +08:00
Li Wang
0aada50b66 Disable transparent hugepages in second kernel
Transparent hugepages are on by default. Disable it in kdump kernel by
adding the parameter 'transparent_hugepage=never'. This might help us
with some of the memory issues we are facing.

From my test on two arch, not only there are no any bad effect on saving vmcore
after turn off THP, but also we can get more 'MemAvailable:' in the kdump kernel.

1)x86_64
without the parameter
=====================
kdump:/# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-229.el7.x86_64 root=/dev/mapper/rhel_ibm--x3250m4--01-root ro rd.lvm.lv=rhel_ibm-x3250m4-01/swap console=ttyS0,115200n8 rd.lvm.lv=rhel_ibm-x3250m4-01/root LANG=en_US.UTF-8 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug disable_cpu_apicid=0 elfcorehdr=869764K

kdump:/# cat /proc/meminfo
MemTotal:         145492 kB
MemFree:           68284 kB
MemAvailable:     111632 kB  <<------
Buffers:              36 kB
Cached:            48184 kB
...

added the parameter
=====================
kdump:/# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-229.el7.x86_64 root=/dev/mapper/rhel_ibm--x3250m4--01-root ro rd.lvm.lv=rhel_ibm-x3250m4-01/swap console=ttyS0,115200n8 rd.lvm.lv=rhel_ibm-x3250m4-01/root LANG=en_US.UTF-8 irqpoll nr_cpus=1 reset_devices cgroup_disable=memory mce=off numa=off udev.children-max=2 panic=10 rootflags=nofail acpi_no_memhotplug transparent_hugepage=never disable_cpu_apicid=0 elfcorehdr=869764K

kdump:/# cat /proc/meminfo
MemTotal:         145492 kB
MemFree:           68388 kB
MemAvailable:     111728 kB  <<-------
...
VmallocChunk:   34359659520 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
...

2)ppc64
without the parameter
====================
kdump:/# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-229.el7.ppc64 root=/dev/mapper/rhel_ibm--p8--05--lp6-root ro rd.lvm.lv=rhel_ibm-p8-05-lp6/root rd.lvm.lv=rhel_ibm-p8-05-lp6/swap LANG=en_US.UTF-8 irqpoll maxcpus=1 noirqdistrib reset_devices cgroup_disable=memory numa=off udev.children-max=2 ehea.use_mcs=0 panic=10 rootflags=nofail kvm_cma_resv_ratio=0 elfcorehdr=154880K

kdump:/# cat /proc/meminfo
MemTotal:         480832 kB
MemFree:          293952 kB
MemAvailable:     427840 kB  <<--------
mallocUsed:       23680 kB
VmallocChunk:   8589901824 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
...

added the parameter
===================
kdump:/# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-229.el7.ppc64 root=/dev/mapper/rhel_ibm--p8--05--lp6-root ro rd.lvm.lv=rhel_ibm-p8-05-lp6/root rd.lvm.lv=rhel_ibm-p8-05-lp6/swap LANG=en_US.UTF-8 irqpoll maxcpus=1 noirqdistrib reset_devices cgroup_disable=memory numa=off udev.children-max=2 ehea.use_mcs=0 panic=10 rootflags=nofail kvm_cma_resv_ratio=0 transparent_hugepage=never elfcorehdr=154880K

kdump:/# cat /proc/meminfo
MemTotal:         480832 kB
MemFree:          294592 kB
MemAvailable:     428480 kB  <<-------
...
HugePages_Total:       0

Signed-off-by: Li Wang <liwang@redhat.com>
Acked-by: Minfei Huang <mhuang@redhat.com>
Acked-by: Baoquan He <bhe@redaht.com>
2015-06-03 21:07:22 +08:00
Baoquan He
cad991814e kdumpctl: adjust the boot dir if kernel is put in sub dir of /boot
Previously /boot is asumed as the default dir where kernel and initrd
is put. However, the directory containing the running kernel image
on Atomic systems differs in each installation. Usually something like:

/boot/ostree/rhel-atomic-host-b50a015b637c353dc6554c851f8a1212b60d6121a7316715e4a63e2a4113cd72

This means that kdump will not find vmlinuz when installed on an
Atomic host, and thus the kdump service will fail to start.

In this patch, the kdump boot dir finding behaviour is a little changed.
Firstly check whether user has specify a directory explicitly in
/etc/sysconfig/kdump. If yes that is respected. Otherwise we assume
1st kernel and kdump kernel are put in the same place under /boot.
Then find it according /proc/cmdline and append it to /boot/

Note:
So now the KDUMP_BOOTDIR in /etc/sysconfig/kdump is set as empty
by default. If user set KDUMP_BOOTDIR to a directory, then he need to
take care of all related things himself. otherwise kdump script handle
it automatically.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Minfei Huang <mhuang@redhat.com>
2015-01-30 14:53:34 +08:00
Baoquan He
1065b91f7d Add acpi_no_memhotplug to kdump kernel
In kdump kernel boot, kdump kernel is booted with memmap= and add
them into e820 map. Then ACPI is initialized and the kernel traverses
the ACPI namespace to find entries for memory device to be hot added.
This adds page table information and the kexec/kdump kernel runs out
of memory.

So in kdump kernel, hot plug memory need be disabled always, only
exact map is trusted. Now add the kernel parameter acpi_no_memhotplug
to kdump kernel cmdline.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-29 16:25:57 +08:00
WANG Chao
7c48f71b6f kdump.sysconfig: default to "nofail" mount
Currently we have two issues against mounting filesystems by systemd.
1. If any failure in sysroot.mount, initrd.target won't be reached.
2. If any failure in mounting /etc/fstab, initrd.target won't be reached

Our kdump.sh is in dracut-pre-pivot hook which is ordered after
initrd.target. That means if systemd doesn't reach initrd.target,
pre-pivot service will not run.

Based on above, we can conclude that in order to run kdump.sh,
initrd.target must be reached.

To fix issue 1), we can add rootflags=nofail to 2nd kernel cmdline, so
that initrd.target will not require sysroot.mount. initrd.target
wouldn't care about the failures in sysroot.mount. That means
initrd.target can always be reached whether or not sysroot.mount fails.
So when initrd.target is reached, kdump.sh can be run.

To fix issue 2), we can append "nofail" mount options to every entry in
/etc/fstab. It has almost the same affects as to sysroot.mount.
initrd.target can be reached whether or not mount /etc/fstab fails. So
when initrd.target is reached, kdump.sh can be run.

If the mount failures block kdump from working properly (for example,
the dump target isn't mounted), the error handling will be done by
"default" action specified in /etc/kdump.conf. Otherwise kdump will
ignore the mount failures and dump as expected.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2013-09-27 15:45:24 +08:00
Baoquan He
070a561da5 Revert: kdump.sysconfig: Add option action_on_fail and set its default as continue
This reverts commit 9e964ff4c6.

Currently, because of dracut implementation, in kdump 'default shell' will
call emergency_shell of dracut. If action_on_fail is enabled, emergency_shell
is skipped. Then 'default shell' won't work either.

Here revert the old commit 9e964ff4 so that take other implementation.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
2013-08-02 14:46:55 +08:00
root
224b700c82 kdump.sysconfig: append "panic=10" to kdump cmdline
When doing kdump If the capture kernel crashes for some reason, the default
behavior appears to be hanging the system without rebooting.  We at least
need an option to reset if the capture kernel crashes.  Business critical
customers tend to want the system to reboot without manual intervention.

Kernel provides a parameter “panic=n” to solve such problem.  If this parameter
is given, the capture kernel will reboot after n seconds in case it panics.

Now add this parameter into “KDUMP_COMMANDLINE_APPEND”, and set the default
waiting time value as 10 seconds.

It's tested on KVM f19, and passed.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-06-13 11:28:12 +08:00
Baoquan He
9e964ff4c6 kdump.sysconfig: Add option action_on_fail and set its default as continue
Upon encountering a failure, dracut can drop user to emergency shell. But
in kdump environment kdump module wants to do the error handling and
wants to handle error as sepecified by user in kdump.conf file (halt,
reboot etc). Now dracut has provided an option action_on_fail=continue
which means dracut just ignores the failure and continues and expects
module to handle the error.

Modify kdump.sysconfig to pass action_on_fail=continue to dracut.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-06-04 10:55:30 +08:00
dyoung@redhat.com
e074e3952b tune sysconfig to save memory usage
tune sysconfig to save 2nd kernel memory usage

The memory in 2nd kernel is limited, we need to use as less memory as we can
to ensure vmcore capturing ok.

I'm doing below improvements in this patch:

1)
numa support is not necessary for kdump kernel, so disable it by adding numa=off
to save some kernel mm memory usage.

2)
Also add udev.children-max=2 to cmdline to limit max udev chidren processes.

3)
For ppc64, ehea driver will by default enable multi queue feature which will
use a lot of memory. Almost each ppc machine will oom for network(ssh/nfs)
kdump. The module param use_mcs=0 is used to disable multi queue feature.

Tested these params on an IBM machine with 2 numa nodes which ooms even for
local dump to rootfs.

With this patch oom does not happen for local/ssh dump, but for nfs dump oom
still happens in the middle of makedumpfile vmcore copying. So there should be
other improvement yet.

For ehea driver there's other params we can use, but because it's hard to
measure the saved memory, I'm waiting for input from IBM people. We can add
them later.

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-02-27 10:16:14 +08:00
Dave Young
ec8e35a790 do not mount root twice
Resolves: bz821997

dracut will mount rootfs for us, so we need not pass root to fstab again here.
Here remove the root-mount line.

This will depends on the root=cmdline is right, by default kdump will
inherit it from /proc/cmdline.

Vivek: add document about the assumption for the root= cmdline issue.

Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2012-07-12 11:15:35 +08:00
Dave Young
ad176c5289 update x86_64 sysconfig
Resolves: bz813711

Sync from rhel6.3 sysconfig

Signed-off-by: Dave Young <dyoung@redhat.com>
2012-04-19 13:52:30 +08:00
Cong Wang
27fddae614 Use nr_cpus=1 instead of maxcpus=1 on x86 2012-01-25 18:44:05 +08:00
Neil Horman
91f6724530 Resolves bz 461615 2008-09-15 13:58:38 +00:00
Neil Horman
558bea7d40 Mass Update of RHEL5 patches 2008-06-05 15:18:53 +00:00
Neil Horman
d3c4b95f8a Updating fc7 with all RHEL5 work 2006-12-15 21:05:01 +00:00