[PATCH 0/3] powerpc: make fadump resilient with memory add/remove events

Sourabh Jain sourabhjain at linux.ibm.com
Sun Sep 17 18:02:22 AEST 2023

due to changes in memory resources caused by either memory hotplug or
online/offline events, the elfcorehdr, which describes the cpus and
memory of the crashed kernel to the kernel that collects the dump (knows
as second/fadump kernel), becomes outdated. consequently, attempting
dump collection with an outdated elfcorehdr can lead to failed or
inaccurate dump collection.

memory hotplug or online/offline events is referred as memory add/remove
events in reset of the patch series.

existing solution:
monitor memory add/remove events in userspace using udev rules, and
re-register fadump whenever there are changes in memory resources. this
leads to the creation of a new elfcorehdr with updated system memory

challenges with existing solution:
1. performing bulk memory add/remove with udev-based fadump
   re-registration can lead to race conditions and, more importantly,
   it creates a wide window during which fadump is inactive until all
   memory add/remove events are settled.
2. re-registering fadump for every memory add/remove event is
3. memory for elfcorehdr is allocated based on the memblock regions
   available during early boot and remains fixed thereafter. however, if
   the elfcorehdr is later recreated with additional memblock regions,
   its size will increase, potentially leading to memory corruption.

proposed solution:
address the aforementioned challenges by shifting the creation of
elfcorehdr from the first kernel (also referred as the crashed kernel),
where it was created and frequently recreated for every memory
add/remove event, to the fadump kernel. as a result, the elfcorehdr only
needs to be created once, thus eliminating the necessity to re-register
fadump during memory add/remove events.

to know more about elfcorehdr creation in the fadump kernel, refer to
the first commit in this patch series.

the second patch includes a new sysfs interface that tells userspace
that fadump re-registration isn't needed for memory add/remove events. 
note that userspace changes do not need to be in sync with kernel
changes; they can roll out independently.

since there are significant changes in the fadump implementation, the
third patch updates the fadump documentation to reflect the changes made
in this patch series.

kernel tree rebased on 6.6-rc1 with patch series applied:

userspace changes:
to realize this feature, one must update the kdump udev rules to prevent
fadump re-registration during memory add/remove events.

on rhel apply the following changes to file

-run+="/bin/sh -c '/usr/bin/systemctl is-active kdump.service || exit 0; /usr/bin/systemd-run --quiet --no-block /usr/lib/udev/kdump-udev-throttler'"
+# don't re-register fadump if the value of the node
+# /sys/kernel/fadump/hotplug_ready is 1.
+run+="/bin/sh -c '/usr/bin/systemctl is-active kdump.service || exit 0; ! test -f /sys/kernel/fadump_enabled || cat /sys/kernel/fadump_enabled | grep 0  || ! test -f /sys/kernel/fadump/hotplug_ready || cat /sys/kernel/fadump/hotplug_ready | grep 0 || exit 0; /usr/bin/systemd-run --quiet --no-block /usr/lib/udev/kdump-udev-throttler'"

Sourabh Jain (3):
  powerpc: make fadump resilient with memory add/remove events
  powerpc/fadump: add hotplug_ready sysfs interface
  Documentation/powerpc: update fadump implementation details

 Documentation/ABI/testing/sysfs-kernel-fadump |  12 +
 .../powerpc/firmware-assisted-dump.rst        |  91 ++---
 arch/powerpc/include/asm/fadump-internal.h    |  24 +-
 arch/powerpc/kernel/fadump.c                  | 370 +++++++++++-------
 arch/powerpc/platforms/powernv/opal-fadump.c  |  18 +-
 arch/powerpc/platforms/pseries/rtas-fadump.c  |  23 +-
 6 files changed, 306 insertions(+), 232 deletions(-)


More information about the Linuxppc-dev mailing list