Commit Graph

346 Commits

Author SHA1 Message Date
Lichen Liu
549f1f9495 Introduce a function to get reserved memory size
Resolves: bz2232499
Upstream: Fedora Rawhide
Conflict: None

commit 4b7b7736ee
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date:   Wed Aug 2 20:36:48 2023 +0530

    Introduce a function to get reserved memory size

    The size of the reserved memory in the functions show_reserved_mem,
    check_crash_mem_reserved, and do_estimate are fetched from the sysfs
    node `/sys/kernel/kexec_crash_size`. However, in the case of fadump,
    the reserved area size is instead present in
    /sys/kernel/fadump/mem_reserved.

    For example:

    $ kdumpctl showmem
    kdump: Dump mode is fadump
    kdump: Reserved 0MB memory for crash kernel

    The above command showed 0MB for Reserved memory which is incorrect, the
    actual reservation was 2048MB.

    To resolve this issue a new helper function is introduced to fetch
    reserved memory size based on the dump mode. For "fadump" mode,
    it looks in `/sys/kernel/fadump/mem_reserved`, otherwise, it uses
    `/sys/kernel/kexec_crash_size`. And all functions that previously
    fetching reserved memory directly from `/sys/kernel/kexec_crash_size`
    sysfs node are now updated to use this new function to get the reserved
    memory size.

    With the fix in place, the `kdumpctl showmem` command will now display
    correct reserved memory size.

    $ kdumpctl showmem
    kdump: Dump mode is fadump
    kdump: Reserved 2048MB memory for crash kernel

    Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Reported-by: Sachin P Bappalige <sachinpb@linux.vnet.ibm.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-09-21 16:24:52 +08:00
Lichen Liu
4a138852ab powerpc: update fadump sysfs node path
Resolves: bz2232499
Upstream: Fedora Rawhide
Conflict: Some newer patches has been rebased, which caused git am to
encounter some problems.

commit fc7c65312a
Author: Sourabh Jain <sourabhjain@linux.ibm.com>
Date:   Thu Aug 17 16:38:35 2023 +0530

    powerpc: update fadump sysfs node path

    The fadump sysfs nodes /sys/kernel/fadump_[enabled|registered], have
    been relocated to /sys/kernel/fadump/[enabled|registered] by kernel
    commits d418b19f34ed ("powerpc/fadump: Reorganize /sys/kernel/fadump_*
    sysfs files").

    To ensure compatibility, symbolic links were added for each relocated
    sysfs entry. Nonetheless, note that these symbolic links might be
    removed later, as they have been deprecated by kernel commit
    3f5f1f22ef10 ("Documentation/ABI: Mark /sys/kernel/fadump_* sysfs files
    deprecated")

    This patch updates the scripts to use the updated fadump sysfs files.

    Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-09-21 15:06:07 +08:00
Lichen Liu
cbb7720e4f kdumpctl: merge check_current_{kdump,fadump}_status
Resolves: bz2232499
Upstream: Fedora Rawhide
Conflict: Some newer patches has been rebased, which caused git am to
encounter some problems.

commit b9fd7a4076
Author: Philipp Rudo <prudo@redhat.com>
Date:   Thu Jan 12 16:31:02 2023 +0100

    kdumpctl: merge check_current_{kdump,fadump}_status

    Both functions are almost identical. The only differences are (1) the
    sysfs node the status is read from and (2) the fact the fadump version
    doesn't verify if the file it's trying to read actually exists. Thus
    merge the two functions and get rid of the check_current_status wrapper.

    While at it rename the function to is_kernel_loaded which explains
    better what the function does.

    Finally, after moving FADUMP_REGISTER_SYS_NODE shellcheck can no longer
    access the definition and starts complaining about it not being quoted.
    Thus quote all uses of FADUMP_REGISTER_SYS_NODE.

    Signed-off-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-09-21 15:02:51 +08:00
Lichen Liu
64c0bfcc53 kdumpctl: remove unnecessary uses of $?
Resolves: bz2232499
Upstream: Fedora Rawhide
Conflict: None

commit b49083126f
Author: Philipp Rudo <prudo@redhat.com>
Date:   Fri Mar 25 15:47:00 2022 +0100

    kdumpctl: remove unnecessary uses of $?

    Signed-off-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Tao Liu <ltao@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-09-21 14:29:58 +08:00
Tao Liu
cb4e527a85 Release 2.0.26-8
Resolves: bz2165018

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-07-04 17:48:08 +08:00
Lichen Liu
fe8c4d3981 spec: kdump/ppc64: make servicelog_notify silent when there are no errors
Resolves: bz2165018
Upstream: Fedora Rawhide
Conflict: None

commit daa829f79e
Author: Lichen Liu <lichliu@redhat.com>
Date:   Mon Jun 12 17:17:43 2023 +0800

    spec: kdump/ppc64: make servicelog_notify silent when there are no errors

    There is confusing message in /var/log/anaconda/packaging.log when installing
    kexec-tools during the system installation on ppc64le:

            Event Notification Registration successful (id: 1)

    Make servicelog_notify slient when there are no erros.

    Signed-off-by: Lichen Liu <lichliu@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-06-27 09:25:17 +08:00
Tao Liu
96de0f6101 Release 2.0.26-7
Resolves: bz2215606
Resolves: bz2165839

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-06-21 16:06:41 +08:00
Tao Liu
401619f484 kdumpctl: Fix temporary directory location
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2215606
Upstream: Fedora Rawhide
Conflict: None

commit dda81d72c2
Author: Philipp Rudo <prudo@redhat.com>
Date:   Mon Jun 19 14:31:48 2023 +0200

    kdumpctl: Fix temporary directory location

    The temporary directory is currently created under the current working
    directory. That alone isn't ideal but works most of the time. However,
    it will fail when the current working directory is not writable. So make
    sure the directory is created within TMPDIR.

    Fixes: ea00b7d ("kdumpctl: Move temp file in get_kernel_size to global temp dir")
    Signed-off-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
2023-06-21 16:02:14 +08:00
Pingfan Liu
d8ee87cfda kdump-lib: Match 64k debug kernel in prepare_kdump_bootinfo()
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2165839
Upstream: Fedora
Conflict: None

commit f3139012f2
Author: Pingfan Liu <piliu@redhat.com>
Date:   Tue Jun 20 08:50:31 2023 +0800

    kdump-lib: Match 64k debug kernel in prepare_kdump_bootinfo()

    For kernel 64k variant, it terminates with substring 64k-debug, e.g.
    vmlinuz-5.14.0-327.el9.aarch64+64k-debug.

    Providing an extra matching pattern to filter out it.

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-20 14:56:52 +08:00
Tao Liu
87bde04c4d Release 2.0.26-6
Resolves: bz2160676
Resolves: bz2165839

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-06-15 17:05:08 +08:00
Pingfan Liu
6189736a11 kdumpctl: Fix the matching of plus symbol by grep's EREs
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: None

commit 64d93c886f
Author: Pingfan Liu <piliu@redhat.com>
Date:   Fri Jun 9 16:04:29 2023 +0800

    kdumpctl: Fix the matching of plus symbol by grep's EREs

    After introducing 64k variant kernel on aarch64, an example kernel name
    looks like "vmlinuz-5.14.0-316.el9.aarch64+64k". To match the plus
    symbol, it demands an escape charater.

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 10:36:54 +08:00
Pingfan Liu
df074ee3de kdump-lib: Evaluate the memory consumption by smmu and mlx5 separately
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: None

commit 7a2c4cbc3b
Author: Pingfan Liu <piliu@redhat.com>
Date:   Tue Jun 13 17:43:23 2023 +0800

    kdump-lib: Evaluate the memory consumption by smmu and mlx5 separately

    On 4k and 64k kernels, the typical consumption values for SMMU are 36MB
    and 384MB, respectively. Hence for 64k kernel, the consumption by smmu
    should be taken into account carefully.

    To do it by adding the extra 384MB value if installing a 64k kernel.
    The upper limit value 384MB is calculated according to the formula in
    the kernel smmu driver.

    As for mlx5 network cards, it is measured by a pratical test, 200M for
    64k variant, 150M for 4k variant

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 10:35:43 +08:00
Pingfan Liu
cde55285bd kdump-lib: add support for 64K aarch64
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: None

commit 05c4861443
Author: Pingfan Liu <piliu at redhat.com>
Date:   Tue Jun 13 17:43:22 2023 +0800

    kdump-lib: add support for 64K aarch64

    On aarch64, both 4K and 64K kernel can be installed, while they demand
    different size reserved memory for kdump kernel.

    'get_conf PAGE_SIZE' can not work if installing a 64K kernel when
    running a 4K kernel. Hence resorting to the kernel release naming rules.
    At present, the 64K kernel has the keyword '64k' in its suffix.

    The base line for 64K is decided based on 4K. The diff 100M is picked up
    since on a high end machine without smmu enabled, the diff of MemFree is
    82M.

    As for the smmu case, a huge difference in the memory consumption lies
    between 64k and 4k driver. And it should be calculated separatedly.

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 10:34:54 +08:00
Pingfan Liu
78e9625b62 kdump-lib: Introduce parse_kver_from_path() to get kernel version from its path name
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: None

commit d8b961be37
Author: Pingfan Liu <piliu@redhat.com>
Date:   Tue Jun 13 17:43:21 2023 +0800

    kdump-lib: Introduce parse_kver_from_path() to get kernel version from its path name

    kdump_get_arch_recommend_crashkernel() expects the kernel version info,
    while _update_kernel() provides the absolute path, which contains the
    kernel version info.

    This patch introduce a dedicated function parse_kver_from_path() to
    extract the kernel info from the path

    Credit to Philipp, who contributes the original code.

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 10:34:05 +08:00
Pingfan Liu
37de94d02a kdump-lib: Introduce a help function _crashkernel_add()
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: Drop shellspec test case

commit 51efbcf83e
Author: Pingfan Liu <piliu@redhat.com>
Date:   Tue Jun 13 17:43:20 2023 +0800

    kdump-lib: Introduce a help function _crashkernel_add()

    This help function can manipulate the crashkernel cmdline by adding an
    number for each item. Also a basic test case for _crashkernel_add() is
    provided in this patch.

    Credit to Philipp, who contributes the original code.

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 10:32:36 +08:00
Pingfan Liu
cb850aec26 Simplify the management of the kernel parameter crashkernel
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2160676
Upstream: Fedora rawhide
Conflict: applied manually due to slight difference in context

commit 5b31b099ae
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed Apr 26 04:48:25 2023 +0800

    Simplify the management of the kernel parameter crashkernel

    Currently, kexec-tools only updates the crashkernel to a new default
    value only when both two conditions are met,
     - auto_reset_crashkernel=yes in kdump.conf
     - existing kernels or current running kernel should use the old default
       value.

    To address seen corner cases, the logic to tell if the second condition
    is met becomes quite complex. Instead of making the logic more complex
    to support aarch64-64k, this patch drops the second condition to
    simplify the management of the crashkernel kernel parameter.

    Another change brought by this simplification is kexec-tools will also
    set up the kernel crashkernel parameter for a fresh install (previously
    it's limited to osbuild).

    Note
    1. This patch also stop trying to update /etc/default/grub because
       a) it only affects the static file /boot/grub2/grub.cfg
       b) grubby is recommended to change the kernel command-line parameters
          for both Fedora [1] and RHEL9 [2][3]
       c) For the cases of aarch64 and POWER, different kernels could have
          different default crashkernel value.

    2. Starting with Fedora 37,  posttrans rpm scriplet distinguish between
       package install and upgrade.

    [1] https://fedoraproject.org/wiki/GRUB_2
    [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/configuring-kernel-command-line-parameters_managing-monitoring-and-updating-the-kernel#changing-kernel-command-line-parameters-for-all-boot-entries_configuring-kernel-command-line-parameters
    [3] https://access.redhat.com/solutions/1136173

    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-15 10:30:53 +08:00
Pingfan Liu
47391b4a6d kdump-lib: fix the matching pattern for debug-kernel
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2165839
Upstream: Fedora
Conflict: None

commit 81d3cc344d
Author: Pingfan Liu <piliu@redhat.com>
Date:   Thu Apr 20 11:26:34 2023 +0800

    kdump-lib: fix the matching pattern for debug-kernel

    On aarch64, a 64k kernel's name looks like:
    vmlinuz-5.14.0-300.el9.aarch64+64k and the corresponding debug kernel's
    name looks like: vmlinuz-5.14.0-300.el9.aarch64+64k-debug, which ends
    with the suffix -debug instead of +debug.

    Fix the matching pattern by [+|-]debug

    Signed-off-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-07 11:59:42 +08:00
Pingfan Liu
4454163cb4 kdump-lib: always specify version in is_squash_available
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2165839
Upstream: Fedora
Conflict: None

commit 88919b73f0
Author: Philipp Rudo <prudo@redhat.com>
Date:   Thu Jan 12 16:31:04 2023 +0100

    kdump-lib: always specify version in is_squash_available

    is_squash_available is only used in dracut-module-setup.sh and mkdumprd.
    Neither of the two scripts calls prepare_kdump_bootinfo which determines
    and sets KDUMP_KERNELVER. Thus KDUMP_KERNELVER is only non-zero if it
    explicitly specified by the user in /etc/sysconfig/kdump (and the file
    gets sourced, which is not the case for drachu-module-setup.sh).

    In theory this can even lead to bugs. For example consider the case when
    a debug kernel is running. In that case kdumpctl will try to use the
    non-debug version of the kernel while is_squash_available will make its
    decision based on the debug version. So in case the debug kernel has
    squash available but the non-debug kernel doesn't mkdumprd will try to
    add it nevertheless.

    Thus factor out the kernel version detection from prepare_kdump_bootinfo
    and make use of the new function when checking for the availability of
    those kernel modules.

    Signed-off-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-06-07 11:59:24 +08:00
Tao Liu
2c6e1b5d4c Release 2.0.26-5
Resolves: bz2144731

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-06-02 11:22:59 +08:00
Tao Liu
6622a1f79e Add lvm thin provision to kdump supported-kdump-targets.txt
Resolves: bz2144731
Upstream: RHEL-only

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-06-02 11:15:37 +08:00
Coiby Xu
26f00a75f0 mkdumprd: Use the correct syntax to redirect the stderr to null
Resolves: https://issues.redhat.com/browse/RHEL-518
Upstream: Fedora
Conflict: None

commit e42a823dae
Author: Coiby Xu <coxu@redhat.com>
Date:   Thu Jun 1 16:05:05 2023 +0800

    mkdumprd: Use the correct syntax to redirect the stderr to null

    A space was added by mistake and unfortunately fips-mode-setup refuses
    an extra parameter,

        # fips-mode-setup --is-enabled 2 > /dev/null
        # echo $?
        2
        # fips-mode-setup --is-enabled 2
        Check, enable, or disable the system FIPS mode.
        usage: /usr/bin/fips-mode-setup --enable|--disable [--no-bootcfg]
        usage: /usr/bin/fips-mode-setup --check
        usage: /usr/bin/fips-mode-setup --is-enabled

    So in this case mkdumprd can never detect if FIPS is enabled. Fix this
    mistake.

    Fixes: 443a43e0 ("mkdumprd: call dracut with --add-device to install the drivers needed by /boot partition automatically for FIPS")
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Tao Liu <ltao@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-06-01 16:42:27 +08:00
Tao Liu
8f66aa349f Release 2.0.26-4
Resovles: bz2169720
Resovles: https://issues.redhat.com/browse/RHEL-512

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-31 15:18:12 +08:00
Tao Liu
206f59eaa6 kdumpctl: Add basic UKI support
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: Small context difference in kexec-tools.spec

commit ea7be0608e
Author: Philipp Rudo <prudo@redhat.com>
Date:   Fri May 5 17:14:42 2023 +0200

    kdumpctl: Add basic UKI support

    A Unified Kernel Image (UKI) is a single EFI PE executable combining an
    EFI stub, a kernel image, an initrd image, and the kernel command line.
    They are defined in the Boot Loader Specification [1] as type #2
    entries. UKIs have the advantage that all code as well as meta data that
    is required to boot the system, not only the kernel image, is combined
    in a single PE file and can be signed for EFI SecureBoot. This extends
    the coverage of SecureBoot extensively.

    For RHEL support for UKI were included into kernel-ark with 16c7e3ee836e
    ("redhat: Add sub-RPM with a EFI unified kernel image for virtual
    machines").

    There are two problems with UKIs from the kdump point of view at the
    moment. First, they cannot be directly loaded via kexec_file_load and
    second, the initrd included isn't suitable for kdump. In order to enable
    kdump on systems with UKIs build the kdump initrd as usual and extract
    the kernel image before loading the crash kernel.

    [1] https://uapi-group.org/specifications/specs/boot_loader_specification/

    Signed-off-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-31 15:11:31 +08:00
Tao Liu
bcd5eb5a45 kdumpctl: Move temp file in get_kernel_size to global temp dir
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: None

commit ea00b7db43
Author: Philipp Rudo <prudo@redhat.com>
Date:   Fri May 5 17:14:41 2023 +0200

    kdumpctl: Move temp file in get_kernel_size to global temp dir

    Others will need to use a temporary files, too. In order to avoid
    potential clashes of multiple trap handlers move the local temp file
    into a global temp dir.

    While at it make sure that the trap handler returns the correct exit
    code.

    Signed-off-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-31 15:10:30 +08:00
Tao Liu
27f67f14ee kdumpctl: Move get_kernel_size to kdumpctl
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: None

commit 81d89c885f
Author: Philipp Rudo <prudo@redhat.com>
Date:   Fri May 5 17:14:40 2023 +0200

    kdumpctl: Move get_kernel_size to kdumpctl

    The function is only used in do_estimate. Move it to kdumpctl to
    prevent confusion.

    Signed-off-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Pingfan Liu <piliu@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-31 15:09:37 +08:00
Tao Liu
411b20cb4a kdump-lib: fix prepare_cmdline
Resolves: bz2169720
Upstream: src.fedoraproject.org/rpms/kexec-tools.git
Conflicts: drop removal of irqpoll in prepare_cmdline due to missing
           d55a056 ("kdumpctl: move aws workaround to kdump-lib") and
           d593bfa ("KDUMP_COMMANDLINE: remove irqpoll parameter on aws aarch64 platform")

commit 0f6ad91be8
Author: Philipp Rudo <prudo@redhat.com>
Date:   Thu Jan 12 16:31:07 2023 +0100

    kdump-lib: fix prepare_cmdline

    A recently added unit test found that prepare_cmdline has several
    problems. For example an empty remove list will remove all spaces or
    when the cmdline contains a parameter with quoted values containing
    spaces will only remove the beginning up to the first space. Furthermore
    the old design requires lots of subshells and pipes.

    This patch rewrites prepare_cmdline in a way that makes the unit test
    happy and tries to use as many bash built-ins as possible.

    Signed-off-by: Philipp Rudo <prudo@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Philipp Rudo <prudo@redhat.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-31 15:08:42 +08:00
Coiby Xu
8507918c04 mkdumprd: call dracut with --add-device to install the drivers needed by /boot partition automatically for FIPS
Resolves: https://issues.redhat.com/browse/RHEL-512
Upstream: Fedora
Conflict: None

commit 443a43e075
Author: Coiby Xu <coxu@redhat.com>
Date:   Wed May 24 12:01:45 2023 +0800

    mkdumprd: call dracut with --add-device to install the drivers needed by /boot partition automatically for FIPS

    Currently, kdump doesn't work on many FIPS-enabled systems including
    Azure, ESXI, Hyper, POWER and etc. When FIPS is enabled, it needs to
    access /boot//.vmlinuz-xxx.hmac to verify the integrity of the kernel.
    However, on those systems, /boot fails to be mounted due to a lack of
    fs and block device drivers and the system just halted after failing to
    verify the integrity of the kernel. For example, on Hyper-V, sd_mod, sg,
    scsi_transport_fc, hv_storvsc and hv_vmbus need to be installed in order
    for /boot to be mounted.

    mkdumprd calls dracut with the --no-hostonly-default-device. Following
    the documentation (man dracut),
        --no-hostonly-default-device
          Do not generate implicit host devices like root, swap, fstab, etc.
          Use "--mount" or "--add-device" to explicitly add devices as needed

    this patch uses "--add-device" to explicitly add the device of /boot.

    Note there is already an attempt to fix it in dracut's 01fips module
    i.e. via the commit 83651776 ("fips: ensure fs module for /boot is
    installed"). Unfortunately it only installs the file system driver e.g.
    xfs.

    Reviewed-by: Philipp Rudo <prudo@redhat.com>
    Signed-off-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-05-29 10:43:57 +08:00
Tao Liu
c04910eebd Release 2.0.26-3
Resovles: bz2173815
Resovles: bz2078176

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-09 18:39:00 +08:00
Tao Liu
3762c208aa Rebase makedumpfile to v1.7.3
Resolves: bz2173815

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-05-09 18:34:18 +08:00
Lichen Liu
3a3c3a924a kdumpctl: lower the log level in reset_crashkernel_for_installed_kernel
Resolves: bz2078176
Upstream: Fedora
Conflict: None

commit d619b6dabe
Author: Lichen Liu <lichliu@redhat.com>
Date:   Tue Apr 4 14:13:14 2023 +0800

    kdumpctl: lower the log level in reset_crashkernel_for_installed_kernel

    Although upgrading the kernel with `rpm -Uvh` is not recommended, the
    kexec-tools plugin prints confusing error logs when a customer upgrades the
    kernel through it.

    ```
    kdump: kernel 5.14.0-80.el9.x86_64 doesn't exist
    kdump: Couldn't find current running kernel
    ```

    Not finding the currently running kernel will only make kdump unable to copy the
    grub entry parameters to the newly installed kernel, so lower the log level.

    Signed-off-by: Lichen Liu <lichliu@redhat.com>
    Reviewed-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-05-06 11:19:16 +08:00
Tao Liu
fa20bd98e5 Release 2.0.26-2
Resovles: bz2173815
Resovles: bz2151504

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-04-21 16:14:51 +08:00
Tao Liu
2ba6f6fb2f Rebase makedumpfile to upstream latest(8e8b8814be1)
Resolves: bz2173815

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-04-21 16:03:34 +08:00
Coiby Xu
a0f7f2ecdf Show how much time kdump has waited for the network to be ready
Related: bz2151504
Upstream: Fedora
Conflict: None

commit 12d9eff9dc
Author: Coiby Xu <coxu@redhat.com>
Date:   Tue Mar 28 16:33:34 2023 +0800

    Show how much time kdump has waited for the network to be ready

    Relates: https://bugzilla.redhat.com/show_bug.cgi?id=2151504

    Currently, when the network isn't ready, kdump would repeatedly print
    the same info,

        [   29.537230] kdump[671]: Bad kdump network destination: 192.123.1.21
        [   30.559418] kdump[679]: Bad kdump network destination: 192.123.1.21
        [   31.580189] kdump[687]: Bad kdump network destination: 192.123.1.21

    This is not user-friendly and users may think kdump has got stuck. So
    also show much time has waited for the network to be ready,

        [   29.546258] kdump[673]: Waiting for network to be ready (50s / 10min)
        ...
        [   32.608967] kdump[697]: Waiting for network to be ready (56s / 10min)

    Note kdump_get_ip_route no longer prints an error message and it's up to
    the caller to determine the log level and print relevant messages. And
    kdump_collect_netif_usage aborts when kdump_get_ip_route fails.

    Reported-by: Martin Pitt <mpitt@redhat.com>
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-04-18 15:26:17 +08:00
Coiby Xu
c28d6fa950 Tell nmcli to not escape colon when getting the path of connection profile
Resolves: bz2151504
Upstream: Fedora
Conflict: None

commit df6f25ff20
Author: Coiby Xu <coxu@redhat.com>
Date:   Mon Mar 27 13:17:32 2023 +0800

    Tell nmcli to not escape colon when getting the path of connection profile

    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2151504

    When a NetworManager connection profile contains a colon in the name,
    "nmcli --get-values UUID,FILENAME" by default would escape the colon
    because a colon is also used for separating the values. In this case,
    99kdumpbase fails to get the correct connection profile path,
            kdumpctl[5439]: cp: cannot stat '/run/NetworkManager/system-connections/static-52\\\:54\\\:01.nmconnection': No such file or directory
            kdumpctl[5440]: sed: can't read /tmp/1977-DRACUT_KDUMP_NM/ifcfg-static-52-54-01: No such file or directory
            kdumpctl[5449]: dracut-install: ERROR: installing '/tmp/1977-DRACUT_KDUMP_NM/ifcfg-static-52-54-01' to '/etc/NetworkManager/system-connections/ifcfg-static-52-54-01'

    As a result, dumping vmcore to a remote nfs would fail.

    In our case of getting connection profile path, there is no need to escape the
    colon so pass "-escape no" to nmcli,

            [root@localhost ~]# nmcli --get-values UUID,FILENAME c show
            659e09c1-a6bd-3549-9be4-a07a1a9a8ffd:/etc/NetworkManager/system-connections/aa\:bb.nmconnection

            [root@localhost ~]# nmcli -escape no --get-values UUID,FILENAME c show
            659e09c1-a6bd-3549-9be4-a07a1a9a8ffd:/etc/NetworkManager/system-connections/aa:bb.nmconnection

    Suggested-by: Beniamino Galvani <bgalvani@redhat.com>
    Reported-by: Martin Pitt <mpitt@redhat.com>
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-04-18 15:25:48 +08:00
Tao Liu
f698814882 Rebase kexec-tools to v2.0.26
Resovles: bz2173814

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-04-07 16:07:26 +08:00
Tao Liu
b9a8a181ac Release 2.0.25-14
Resolves: bz2140721
Resolves: bz2177574
Resolves: bz2177674

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-03-21 16:09:11 +08:00
Coiby Xu
5f9fa02614 Install nfsv4-related drivers when users specify nfs dumping via dracut_args
Resolves: bz2140721
Upstream: Fedora
Conflict: None

commit 70c7598ef0
Author: Coiby Xu <coxu@redhat.com>
Date:   Fri Dec 23 16:03:38 2022 +0800

    Install nfsv4-related drivers when users specify nfs dumping via dracut_args

    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2140721

    Currently, if users specify dumping to nfsv4 target via
      dracut_args --mount "<NFS-server-ip>:/var/crash /mnt nfs defaults"
    it fails with the following errors,
        [    5.159760] mount[446]: mount.nfs: Protocol not supported
        [    5.164502] systemd[1]: mnt.mount: Mount process exited, code=exited, status=32/n/a
        [    5.167616] systemd[1]: mnt.mount: Failed with result 'exit-code'.
        [FAILED] Failed to mount /mnt.

    This is because nfsv4-releted drivers are not installed to kdump initrd.
    mkdumprd calls dracut with "--hostonly-mode strict". If nfsv4-related
    drivers aren't loaded before calling dracut, they won't be installed.
    When users specify nfs dumping via dracut_args, kexec-tools won't mount
    the nfs fs beforehand hence nfsv4-related drivers won't be installed.
    Note dracut only installs the nfs driver i.e. nfsv3 driver for "--mount
    ... nfs". So also install nfsv4-related drivers when users specify nfs
    dumping via dracut_args. Since nfs_layout_nfsv41_files depends on nfsv4,
    the nfsv4 driver will be installed automatically.

    As for the reason why we support nfs dumping via dracut_args instead of
    asking user to use the nfs directive, please refer to commit 74c6f464
    ("Support special mount information via 'dracut_args'").

    Fixes: 4eedcae5 ("dracut-module-setup.sh: don't include multipath-hostonly")
    Reported-by: rcheerla@redhat.com
    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Philipp Rudo <prudo@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-03-21 16:01:22 +08:00
Pingfan Liu
2b2b6b84c0 Revert "ppc64: tackle SRCU hang issue"
Resolves: bz2177574
Upstream: RHEL-only

This reverts commit 870ec2ec93.

Now the real fix has gone into the RHEL-9 kernel [1], the temporary
workaround can be removed.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2129726

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-03-21 07:50:06 +00:00
Philipp Rudo
2f5889df5e sysconfig: add zfcp.allow_lun_scan to KDUMP_COMMANDLINE_REMOVE on s390
Resolves: bz2177674
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>
2023-03-13 13:41:05 +01:00
Tao Liu
fe7198e928 Release 2.0.25-13
Resolves: bz2174836

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-03-10 11:14:01 +08:00
Lichen Liu
67f450cc9f kdump-lib: Add the CoreOS kernel dir to the boot_dirlist
Resolves: bz2174836
Upstream: Fedora
Conflict: None

commit f9c32372d2
Author: Lichen Liu <lichliu@redhat.com>
Date:   Tue Jun 21 16:55:09 2022 +0800

    kdump-lib: Add the CoreOS kernel dir to the boot_dirlist

    The kernel of CoreOS is not in the standard locations, add
    /boot/ostree/* to the boot_dirlist to find the vmlinuz.

    Signed-off-by: Lichen Liu <lichliu@redhat.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-03-07 10:42:24 +08:00
Lichen Liu
1eb996d08f kdump-lib: attempt to fix BOOT_IMAGE detection
Resolves: bz2174836
Upstream: Fedora
Conflict: None

commit f9c32372d2
Author: Dusty Mabe <dusty@dustymabe.com>
Date:   Wed Jun 22 12:34:12 2022 -0400

    kdump-lib: attempt to fix BOOT_IMAGE detection

    Currently $boot_img can get bad data if running on a platform
    that doesn't set BOOT_IMAGE in the kernel command line. For
    example, currently:

    - s390x Fedora CoreOS machine:

    ```
    [root@cosa-devsh ~]# sed "s/^BOOT_IMAGE=\((\S*)\)\?\(\S*\) .*/\2/" /proc/cmdline
    mitigations=auto,nosmt ignition.platform.id=qemu ostree=/ostree/boot.0/fedora-coreos/2a72567ac8f7ed678c3ac89408f795e6ccd4e97b41e14af5f471b6a807e858b9/0 root=UUID=2a88436a-3b6b-4706-b33a-b8270bd87cde rw rootflags=prjquota boot=UUID=f4b2eaa5-9317-4798-85cf-308c477fee4c crashkernel=600M
    ```

    where on a platform that uses GRUB we get:

    - x86_64 Fedora CoreOS machine:

    ```
    [root@cosa-devsh ~]# sed "s/^BOOT_IMAGE=\((\S*)\)\?\(\S*\) .*/\2/" /proc/cmdline
    /ostree/fedora-coreos-af4f6cc7b9ff486cfa647680b180e989c72c8eed03a34a42e7328e49332bd20e/vmlinuz-5.18.5-200.fc36.x86_64
    ```

    We should change the setting of the boot_img variable such that it will
    be empty if BOOT_IMAGE doesn't exist.

    With this change on the s390x machine:

    ```
    [root@cosa-devsh ~]# grep -P -o '^BOOT_IMAGE=(\S+)' /proc/cmdline | sed "s/^BOOT_IMAGE=\((\S*)\)\?\(\S*\)/\2/"
    [root@cosa-devsh ~]#
    ```

    This change mattered much more before the change in c5bdd2d which changed
    the following line from [[ -n $boot_img ]] to [[ "$boot_img" == *"$kdump_kernelver" ]].
    Still I think this change has merit.

    Signed-off-by: Dusty Mabe <dusty@dustymabe.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-03-07 10:41:50 +08:00
Lichen Liu
0cecfa7d45 kdump-lib: change how ostree based systems are detected
Resolves: bz2174836
Upstream: Fedora
Conflict: None

commit a1ebf0b565
Author: Dusty Mabe <dusty@dustymabe.com>
Date:   Fri Jun 24 09:57:03 2022 -0400

    kdump-lib: change how ostree based systems are detected

    The current recommendation is to check for /run/ostree-booted.

    See https://bugzilla.redhat.com/show_bug.cgi?id=2092012#c0

    Signed-off-by: Dusty Mabe <dusty@dustymabe.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-03-07 10:41:26 +08:00
Lichen Liu
e47ec659e9 kdump-lib: clear up references to Atomic/CoreOS
Resolves: bz2174836
Upstream: Fedora
Conflict: None

commit 980f10aa40
Author: Dusty Mabe <dusty@dustymabe.com>
Date:   Wed Jun 22 11:58:31 2022 -0400

    kdump-lib: clear up references to Atomic/CoreOS

    There are many variants on OSTree based systems these days so
    we should probably refer to the class of systems as "OSTree
    based systems". Also, Atomic Host is dead.

    Signed-off-by: Dusty Mabe <dusty@dustymabe.com>
    Acked-by: Coiby Xu <coxu@redhat.com>

Signed-off-by: Lichen Liu <lichliu@redhat.com>
2023-03-07 10:40:52 +08:00
Tao Liu
577dc4415a Release 2.0.25-12
Resolves: bz2168504
Related: bz2060319

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-02-24 14:06:46 +08:00
Coiby Xu
ae272e2df8 Reset crashkernel to default value if newly installed kernel has crashkernel=auto
Resolves: bz2168504
Upstream: RHEL-only

After leapp upgrade from 8.8 to 9.2 on Azure,  RHEL9 kernel has
crashkernel=auto. This happens because kexec-tools's posttrans scriptlet
is executed before kernel's posttrans scriptlet (which in turn runs the
kernel-install hooks). One of the kernel-install hook is responsible for
adding a new boot entry for the new kernel. So when kexec-tools's posttrans
scriptlet is running, RHEL9 kernel is yet to have a boot entry so
kexec-tools couldn't set up the crashkernel parameter. Later one
kernel-install hook makes RHEL9 kernel inherit crashkernel=auto.

Fix this issue by letting 92-crashkernel.install reset crashkernel=auto.

Reported-by: Yuxin Sun <yuxisun@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-02-23 09:21:47 +08:00
Coiby Xu
ef81bb9f44 Use the correct command to get architecture
Related: bz2060319
Upstream: Fedora
Conflict: None

commit 12e6cd2b76
Author: Coiby Xu <coxu@redhat.com>
Date:   Mon Feb 20 17:33:08 2023 +0800

    Use the correct command to get architecture

    `uname -r` was used by mistake. As a result, kexec-tools failed to
    update crashkernel=auto during in-place upgrade from RHEL8 to RHEL9.

    `uname -m` should be used to get architecture instead.

    Fixes: 5951b5e2 ("Don't try to update crashkernel when bootloader is not installed")

    Signed-off-by: Coiby Xu <coxu@redhat.com>
    Reviewed-by: Lichen Liu <lichliu@redhat.com>

Signed-off-by: Coiby Xu <coxu@redhat.com>
2023-02-21 12:16:09 +08:00
Tao Liu
a95e71e516 Release 2.0.25-11
Resolves: bz2158296

Signed-off-by: Tao Liu <ltao@redhat.com>
2023-01-11 17:17:15 +08:00
Pingfan Liu
870ec2ec93 ppc64: tackle SRCU hang issue
Resolves: bz2158296
Upstream: RHEL-only

On PowerPC platform, the following hang is witnessed:

Welcome to
Red Hat Enterprise Linux 9.2 Beta (Plow) dracut-057-13.git20220816.el9 (Initramfs)
!

[    1.631210] systemd[1]: Hostname set to <ibm-p9z-18-lp11.virt.pnr.lab.eng.rdu2.redhat.com>.
[-- MARK -- Mon Sep 26 01:45:00 2022]
[  243.681283] INFO: task systemd:1 blocked for more than 122 seconds.
[  243.681303]       Not tainted 5.14.0-167.el9.ppc64le #1
[  243.681315] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  243.681329] task:systemd         state:D stack:    0 pid:    1 ppid:     0 flags:0x00042000
[  243.681349] Call Trace:
[  243.681356] [c00000001a603640] [c00000004f990100] 0xc00000004f990100 (unreliable)
[  243.681378] [c00000001a603830] [c00000001001e9cc] __switch_to+0x12c/0x220
[  243.681400] [c00000001a603890] [c000000010ec5b40] __schedule+0x230/0x720
[  243.681418] [c00000001a603950] [c000000010ec6090] schedule+0x60/0x110
[  243.681435] [c00000001a603980] [c000000010ecd948] schedule_timeout+0x168/0x1c0
[  243.681454] [c00000001a603a60] [c000000010ec7214] __wait_for_common+0x134/0x360
[  243.681473] [c00000001a603b00] [c00000001017c98c] __flush_work.isra.0+0x1dc/0x3d0
[  243.681493] [c00000001a603ba0] [c0000000105cbd88] fsnotify_wait_marks_destroyed+0x28/0x40
[  243.681512] [c00000001a603bc0] [c0000000105cb800] fsnotify_destroy_group+0x60/0x150
[  243.681531] [c00000001a603c30] [c0000000105cf640] inotify_release+0x30/0xa0
[  243.681548] [c00000001a603ca0] [c00000001054fad8] __fput+0xc8/0x350
[  243.681565] [c00000001a603cf0] [c000000010183174] task_work_run+0xe4/0x160
[  243.681583] [c00000001a603d40] [c000000010021874] do_notify_resume+0x134/0x140
[  243.681602] [c00000001a603d70] [c000000010030168] interrupt_exit_user_prepare_main+0x198/0x270
[  243.681622] [c00000001a603de0] [c0000000100305ac] syscall_exit_prepare+0x6c/0x180
[  243.681641] [c00000001a603e10] [c00000001000bff4] system_call_vectored_common+0xf4/0x278
[  243.681661] --- interrupt: 3000 at 0x7fffb3015ba4
[  243.681673] NIP:  00007fffb3015ba4 LR: 0000000000000000 CTR: 0000000000000000
[  243.681687] REGS: c00000001a603e80 TRAP: 3000   Not tainted  (5.14.0-167.el9.ppc64le)
[  243.681703] MSR:  800000000000d033 <SF,EE,PR,ME,IR,DR,RI,LE>  CR: 42044440  XER: 00000000
[  243.681737] IRQMASK: 0
[  243.681737] GPR00: 0000000000000006 00007fffd24a31a0 00007fffb3127200 0000000000000000
[  243.681737] GPR04: 0000000000000002 000000000000000a 0000000000000000 0000000000000000
[  243.681737] GPR08: 0000010009ea2d40 0000000000000000 0000000000000000 0000000000000000
[  243.681737] GPR12: 0000000000000000 00007fffb3834bc0 0000000000000000 0000000000000000
[  243.681737] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[  243.681737] GPR20: 000000012c74ddf0 000000000000000e 000000000017cd3f 0000000000000000
[  243.681737] GPR24: 00007fffd24a3570 0000000000000005 0000010009eb5490 0000010009ea24e0
[  243.681737] GPR28: 0000010009ea2900 0000010009eb4850 0000010009ea2d70 00007fffb382dd98
[  243.681896] NIP [00007fffb3015ba4] 0x7fffb3015ba4
[  243.681907] LR [0000000000000000] 0x0
[  243.681917] --- interrupt: 3000
[  243.681928] INFO: task kworker/u16:1:34 blocked for more than 122 seconds.
[  243.681941]       Not tainted 5.14.0-167.el9.ppc64le #1
[  243.681951] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  243.681964] task:kworker/u16:1   state:D stack:    0 pid:   34 ppid:     2 flags:0x00000800
[  243.681982] Workqueue: events_unbound fsnotify_mark_destroy_workfn
[  243.681998] Call Trace:
[  243.682005] [c00000001a9336d0] [c00000004f990100] 0xc00000004f990100 (unreliable)
[  243.682023] [c00000001a9338c0] [c00000001001e9cc] __switch_to+0x12c/0x220
[  243.682042] [c00000001a933920] [c000000010ec5b40] __schedule+0x230/0x720
[  243.682059] [c00000001a9339e0] [c000000010ec6090] schedule+0x60/0x110
[  243.682075] [c00000001a933a10] [c000000010ecd948] schedule_timeout+0x168/0x1c0
[  243.682094] [c00000001a933af0] [c000000010ec7214] __wait_for_common+0x134/0x360
[  243.682113] [c00000001a933b90] [c000000010213370] __synchronize_srcu.part.0+0xa0/0xe0
[  243.682132] [c00000001a933c00] [c0000000105cc154] fsnotify_mark_destroy_workfn+0xc4/0x1a0
[  243.682151] [c00000001a933c70] [c00000001017acb8] process_one_work+0x298/0x580
[  243.682169] [c00000001a933d10] [c00000001017b048] worker_thread+0xa8/0x630
[  243.682185] [c00000001a933da0] [c000000010188348] kthread+0x1b8/0x1c0
[  243.682203] [c00000001a933e10] [c00000001000cd64] ret_from_kernel_thread+0x5c/0x64
[  366.561279] INFO: task systemd:1 blocked for more than 245 seconds.

The right solution should be in kernel, but since the patch [1] for SRCU
will not be merged into the mainline in near future, it had better to
have a userspace workaround to overcome this test blocker.

The workaround method is to pass the kernel parameter "srcutree.big_cpu_lim=0", so
that the SRCU system will always use srcu_node array.

[1]: https://lore.kernel.org/rcu/20221026032716.78674-1-kernelfans@gmail.com/T/#m6534975507c2abca497a94d81c7abbfea1d0978d

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2023-01-06 11:26:03 +08:00
Pingfan Liu
54d8965261 Release 2.0.25-10
Resolves: bz2151500
Resolves: bz2060319
Resolves: bz2151842
Resolves: bz2139000

Signed-off-by: Pingfan Liu <piliu@redhat.com>
2022-12-27 15:11:50 +08:00