Hello community,

here is the log from the commit of package kdump for openSUSE:Factory checked 
in at 2018-10-15 10:04:57
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/kdump (Old)
 and      /work/SRC/openSUSE:Factory/.kdump.new (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Package is "kdump"

Mon Oct 15 10:04:57 2018 rev:101 rq:640101 version:0.9.0

Changes:
--------
--- /work/SRC/openSUSE:Factory/kdump/kdump.changes      2018-05-23 
16:06:12.728332549 +0200
+++ /work/SRC/openSUSE:Factory/.kdump.new/kdump.changes 2018-10-15 
10:05:01.661949832 +0200
@@ -1,0 +2,22 @@
+Fri Oct  5 14:31:49 UTC 2018 - [email protected]
+
+- kdump-turn-off-NUMA-in-kdump-kernel.patch: Turn off NUMA in the
+  kdump kernel (bsc#1109784, bsc#1102609).
+
+-------------------------------------------------------------------
+Fri Oct  5 14:29:47 UTC 2018 - [email protected]
+
+- kdump-fadump-add-udev-support.patch: fadump: add udev event
+  support for fadump (bsc#1108170).
+
+-------------------------------------------------------------------
+Fri Oct  5 14:28:01 UTC 2018 - [email protected]
+
+- kdump-fadump-avoid-multipath-optimizations.patch: fadump: avoid
+  multipath optimizations that break regular boot (bsc#1101730).
+- kdump-split-cmdline-purpose-wise.patch: cmdline: split kdump
+  cmdline purpose wise (bsc#1101730).
+- kdump-fadump-fix-network-bring-up.patch: fadump: fix network
+  bring up issue during default boot (bsc#1101730).
+
+-------------------------------------------------------------------

New:
----
  kdump-fadump-add-udev-support.patch
  kdump-fadump-avoid-multipath-optimizations.patch
  kdump-fadump-fix-network-bring-up.patch
  kdump-split-cmdline-purpose-wise.patch
  kdump-turn-off-NUMA-in-kdump-kernel.patch

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Other differences:
------------------
++++++ kdump.spec ++++++
--- /var/tmp/diff_new_pack.OQBX3c/_old  2018-10-15 10:05:02.045949419 +0200
+++ /var/tmp/diff_new_pack.OQBX3c/_new  2018-10-15 10:05:02.049949414 +0200
@@ -48,6 +48,11 @@
 Source2:        %{name}-rpmlintrc
 Patch1:         %{name}-fillupdir-fixes.patch
 Patch2:         %{name}-block-initrd-parse-etc.service.patch
+Patch3:         %{name}-fadump-avoid-multipath-optimizations.patch
+Patch4:         %{name}-split-cmdline-purpose-wise.patch
+Patch5:         %{name}-fadump-fix-network-bring-up.patch
+Patch6:         %{name}-fadump-add-udev-support.patch
+Patch7:         %{name}-turn-off-NUMA-in-kdump-kernel.patch
 BuildRequires:  asciidoc
 BuildRequires:  cmake
 BuildRequires:  gcc-c++
@@ -107,6 +112,11 @@
 %patch1 -p1
 %endif
 %patch2 -p1
+%patch3 -p1
+%patch4 -p1
+%patch5 -p1
+%patch6 -p1
+%patch7 -p1
 
 %build
 export CFLAGS="%{optflags}"

++++++ kdump-fadump-add-udev-support.patch ++++++
From: Hari Bathini <[email protected]>
Subject: fadump: add udev event support for fadump
References: bsc#1108170
Upstream: merged
Git-commit: eb5784f6cb8368b346b9b52be66116fc5a47f720

Currently, the udev rules written in kdump package only support reloading
kdump on memory/cpu hot add/remove operation. But this is needed as much
for FADump as well. The rules were not updated to support fadump owing to
lack of support in the kernel for re-registering FADump. This support is
now added to kernel with commit 0823c68b054b ("powerpc/fadump: re-register
firmware-assisted dump if already registered"). Update kdump udev rules
to load fadump on memory/cpu DLPAR operations.

Signed-off-by: Hari Bathini <[email protected]>
Signed-off-by: Petr Tesarik <[email protected]>
---
 70-kdump.rules.in |    3 +++
 init/load.sh      |   29 ++++++++++++++++-------------
 2 files changed, 19 insertions(+), 13 deletions(-)

--- a/70-kdump.rules.in
+++ b/70-kdump.rules.in
@@ -21,6 +21,9 @@ GOTO="kdump_end"
 # Reload only if panic kernel is already loaded
 LABEL="kdump_try_restart"
 PROGRAM="/bin/cat /sys/kernel/kexec_crash_loaded", RESULT!="0", 
RUN+="/lib/kdump/load-once.sh"
+@if @ARCH@ ppc64 ppc64le
+TEST=="/sys/kernel/fadump_registered", PROGRAM="/bin/cat 
/sys/kernel/fadump_registered", RESULT!="0", RUN+="/lib/kdump/load-once.sh"
+@endif
 
 LABEL="kdump_end"
 @endif
--- a/init/load.sh
+++ b/init/load.sh
@@ -243,21 +243,24 @@ function load_kdump_fadump()
 
     local msg
     local result=0
+    local output
 
-    # The kernel fails with EINVAL if registered already
-    # (see bnc#814780)
-    if [ "$(cat $FADUMP_REGISTERED)" != "1" ] ; then
-        local output
-
-        output=$( (echo 1 > "$FADUMP_REGISTERED") 2>&1)
-        if [ $? -eq 0 ] ; then
-           msg="Registered fadump"
-       else
-           msg="FAILED to register fadump: $output"
-            result=1
-       fi
+    # Re-registering of FADump is supported in kernel (see bsc#1108170).
+    # So, don't bother about whether FADump was registered already
+    output=$( (echo 1 > "$FADUMP_REGISTERED") 2>&1)
+    if [ $? -eq 0 ] ; then
+        msg="Registered fadump"
     else
-       msg="fadump is already registered"
+        # For backward compatibility on older kernel that
+        # returns -EEXIST/-EINVAL
+        if [ "$(cat $FADUMP_REGISTERED)" == "1" ] ; then
+            # TODO: unregiser/register OR warn user to stop/start?
+            # Best bet is to update to latest kernel.
+            msg="fadump is already registered"
+        else
+            msg="FAILED to register fadump: $output"
+            result=1
+        fi
     fi
 
     echo "$msg"
++++++ kdump-fadump-avoid-multipath-optimizations.patch ++++++
From: Hari Bathini <[email protected]>
Date: Mon, 20 Aug 2018 16:11:38 +0200
Subject: fadump: avoid multipath optimizations that break regular boot
References: bsc#1101730
Upstream: merged
Git-commit: dc29a820687a3a267c56ad1b125cb670dbd194ad

Since commit 9a3764178a91 ("Blacklist unneeded multipath devices")
multipath devices that are not needed while capturing dump were
blacklisted. This reduces the memory requirements on kdump kernel.
But when this optimization is added to default initrd by including
dump capturing support for FADump, it is observed to mess with the
initialization of such blacklisted multipath devices while booting
the production kernel. To avoid such issues, use this optimization
only while booting a capture kernel.

Signed-off-by: Hari Bathini <[email protected]>
Acked-by: Petr Tesarik <[email protected]>
---
 init/CMakeLists.txt        |    1 +
 init/kdump-boot.sh         |   16 ++++++++++++++++
 init/module-setup.sh       |    1 +
 init/setup-kdump.functions |    2 +-
 4 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100755 init/kdump-boot.sh

--- a/init/CMakeLists.txt
+++ b/init/CMakeLists.txt
@@ -98,6 +98,7 @@ INSTALL(
 INSTALL(
     FILES
         ${CMAKE_CURRENT_SOURCE_DIR}/kdump-root.sh
+        ${CMAKE_CURRENT_SOURCE_DIR}/kdump-boot.sh
         ${CMAKE_CURRENT_SOURCE_DIR}/module-setup.sh
         ${CMAKE_CURRENT_SOURCE_DIR}/mount-kdump.sh
     DESTINATION
--- /dev/null
+++ b/init/kdump-boot.sh
@@ -0,0 +1,16 @@
+#! /bin/sh
+# -*- mode: shell-script; indent-tabs-mode: nil; sh-basic-offset: 4; -*-
+# ex: ts=8 sw=4 sts=4 et filetype=sh
+
+# An Initrd with dump capturing support can boot a production kernel
+# as well (FADump). In such scenario, apply optimizations only while
+# booting the capture kernel - this is a kernel that
+#   a) has a /proc/vmcore file waiting to be saved.
+#   b) reboots after saving the dump.
+
+# apply multipath optimizations
+if [ -s /proc/vmcore ]; then
+    # Replace the multipath.conf file with the one optimized for kdump.
+    rm -f /etc/multipath.conf
+    mv /etc/multipath.conf.kdump /etc/multipath.conf
+fi
--- a/init/module-setup.sh
+++ b/init/module-setup.sh
@@ -264,6 +264,7 @@ install() {
     kdump_setup_files "$initdir" "$kdump_mpath_wwids"
 
     inst_hook cmdline 50 "$moddir/kdump-root.sh"
+    inst_hook cmdline 50 "$moddir/kdump-boot.sh"
     if dracut_module_included "systemd" ; then
        inst_binary "$moddir/device-timeout-generator" \
            "$systemdutildir"/system-generators/kdump-device-timeout-generator
--- a/init/setup-kdump.functions
+++ b/init/setup-kdump.functions
@@ -1179,7 +1179,7 @@ function kdump_setup_files()                              
                   # {
     #
     # create modified multipath.conf
     #
-    kdump_modify_multipath "$mpathdevs" > "${outdir}/etc/multipath.conf"
+    kdump_modify_multipath "$mpathdevs" > "${outdir}/etc/multipath.conf.kdump"
 
     #
     # filter out problematic sysctl settings
++++++ kdump-fadump-fix-network-bring-up.patch ++++++
From: Hari Bathini <[email protected]>
Date: Mon, 20 Aug 2018 16:12:51 +0200
Subject: fadump: fix network bring up issue during default boot
References: bsc#1101730
Upstream: merged
Git-commit: 0ad221c8a81ee812b3afec6a9c873bd5bd1c228b

If ssh is used for dump target, kdump module enforces bringing up the
network (rd.neednet=1). If bringing up the network fails, it drops to
emergency shell. This sounds ok for a kdump kernel as it's only job is
to save dump to the specified dump target and reboot. But in case of
FADump, kdump module, which adds dump capturing support in the initrd,
is added to the regular initrd. If network bring up fails, production
kernel also falls to emergency shell while booting. Considering this
requirement has no relevance in booting a production kerne, that could
have been avoided. Fix it here by enforcing rd.neednet=1 only while
booting a capture kernel.

Signed-off-by: Hari Bathini <[email protected]>
Acked-by: Petr Tesarik <[email protected]>
---
 init/kdump-boot.sh |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/init/kdump-boot.sh
+++ b/init/kdump-boot.sh
@@ -3,8 +3,9 @@
 # ex: ts=8 sw=4 sts=4 et filetype=sh
 
 # An Initrd with dump capturing support can boot a production kernel
-# as well (FADump). In such scenario, apply optimizations only while
-# booting the capture kernel - this is a kernel that
+# as well (FADump). In such scenario, apply optimizations and enforce
+# bringing up dump target only while booting the capture kernel - this
+# is a kernel that
 #   a) has a /proc/vmcore file waiting to be saved.
 #   b) reboots after saving the dump.
 
@@ -13,4 +14,7 @@ if [ -s /proc/vmcore ]; then
     # Replace the multipath.conf file with the one optimized for kdump.
     rm -f /etc/multipath.conf
     mv /etc/multipath.conf.kdump /etc/multipath.conf
+else
+    # avoid enforing network bring up while booting production kernel.
+    rm -f /etc/cmdline.d/99kdump-net.conf
 fi
++++++ kdump-split-cmdline-purpose-wise.patch ++++++
From: Hari Bathini <[email protected]>
Date: Mon, 20 Aug 2018 16:12:46 +0200
Subject: cmdline: split kdump cmdline purpose wise
References: bsc#1101730
Upstream: merged
Git-commit: 56c8821596ee64c400e66002d17449007d1bd5f0

Generate different cmdline files for different purposes. This gives
flexibilty in handling them independently. The subsequent patch uses
this in handling network bringup more gracefully.

Signed-off-by: Hari Bathini <[email protected]>
Acked-by: Petr Tesarik <[email protected]>
---
 init/module-setup.sh |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/init/module-setup.sh
+++ b/init/module-setup.sh
@@ -205,10 +205,12 @@ kdump_cmdline_ip() {
     esac
 }
 
-cmdline() {
+cmdline_zfcp() {
     local _arch=$(uname -m)
     [ "$_arch" = "s390" -o "$_arch" = "s390x" ] && kdump_cmdline_zfcp
+}
 
+cmdline_net() {
     kdump_cmdline_ip
 }
 
@@ -219,8 +221,11 @@ installkernel() {
 
 install() {
     if [[ $hostonly_cmdline == "yes" ]] ; then
-        local _cmdline=$(cmdline)
-        [ -n "$_cmdline" ] && printf "%s\n" "$_cmdline" >> 
"${initdir}/etc/cmdline.d/99kdump.conf"
+        local _cmdline=$(cmdline_zfcp)
+        [ -n "$_cmdline" ] && printf "%s\n" "$_cmdline" >> 
"${initdir}/etc/cmdline.d/99kdump-zfcp.conf"
+
+        _cmdline=$(cmdline_net)
+        [ -n "$_cmdline" ] && printf "%s\n" "$_cmdline" >> 
"${initdir}/etc/cmdline.d/99kdump-net.conf"
     fi
 
     # Get a list of required multipath devices
++++++ kdump-turn-off-NUMA-in-kdump-kernel.patch ++++++
From: Petr Tesarik <[email protected]>
Date: Tue, 25 Sep 2018 09:23:04 +0200
Subject: Turn off NUMA in the kdump kernel
References: bsc#1109784, bsc#1102609
Upstream: merged
Git-commit: 4c0e78b9923f0dbba3ad1bacc2336d91f7b520e5

On NUMA systems, the crashkernel reserved region may get allocated
on a different node than the low region (memory below 4G). With NUMA
optimization turned on, the kernel will prefer node-local pages for
all page allocations, which may unnecessarily deplete the DMA and
DMA32 regions with data that could be allocated from the Normal
zone (which is on a remote node).

It makes little sense to address this corner case in the memory
management system, because nobody would build a machine with almost
all memory on a remote node. So, instead, let's turn off NUMA for
kdump and accept the potential performance hit.

Signed-off-by: Petr Tesarik <[email protected]>
---
 init/load.sh |    1 +
 1 file changed, 1 insertion(+)

--- a/init/load.sh
+++ b/init/load.sh
@@ -73,6 +73,7 @@ function build_kdump_commandline()
         fi
         # Use deadline for saving the memory footprint
         commandline="$commandline elevator=deadline sysrq=yes reset_devices 
acpi_no_memhotplug cgroup_disable=memory nokaslr"
+        commandline="$commandline numa=off"
         commandline="$commandline irqpoll ${nr_cpus}"
         commandline="$commandline root=kdump rootflags=bind 
rd.udev.children-max=8"
         case $(uname -i) in

Reply via email to