ppc/fadump: invoke kmsg_dump in fadump panic path

PATCH Applied Shivang Upadhyay 5 participants 6 messages Apr 12 – Jun 19 PowerPC

Share & tools

Shivang Upadhyay

author

2026-04-12 11:31 UTC #0 lore raw

PATCH v2 1/1 ppc/fadump: invoke kmsg_dump in fadump panic path

fadump is registered in panic_notifier_list and gets triggered before kmsg_dump_desc() in the panic path. As a result, kmsg_dumpers such as pstore are not executed during fadump crashes.

This is problematic because pstore provides a critical fallback mechanism for crash analysis. When fadump fails to successfully reboot the system or capture a dump, pstore logs may be the only available information from the crashed kernel. Without invoking kmsg_dump_desc() in the fadump path, we lose this valuable diagnostic data.

Invoke kmsg_dump_desc() from the fadump panic handler, but only when fadump is actually registered (checked via should_fadump_crash()). This ensures kmsg_dumpers are called without duplicating the call that occurs later in panic() when fadump is not active.

The call is placed before crash_fadump() to ensure logs are captured before the system attempts to trigger the firmware-assisted dump.

Cc Hari Bathini <[email protected]>

Cc Madhavan Srinivasan <[email protected]>

Cc Mahesh Salgaonkar <[email protected]>

Cc Michael Ellerman <[email protected]>

Cc Ritesh Harjani (IBM) <[email protected]>

Reported-by Shirisha G <[email protected]>

Signed-off-by Shivang Upadhyay <[email protected]>

---
Changelog:

v2:
address comments from Sourabh, and sashikio-ai
added should_fadump_crash()

v1:
https://lore.kernel.org/all/[email protected]/

---
 arch/powerpc/kernel/setup-common.c | 8 ++++++++
 1 file changed, 8 insertions(+)

arch/powerpc/kernel/setup-common.c +8 -0

index b1761909c23f..87afc8003a03 100644
@@ -68,6 +68,7 @@
 #include <asm/kasan.h>
 #include <asm/mce.h>
 #include <asm/systemcfg.h>
+#include <linux/kmsg_dump.h>
 
 #include "setup.h"

@@ -744,6 +745,13 @@ static int ppc_panic_fadump_handler(struct notifier_block *this,
 	 */
 	hard_irq_disable();
 
+	/*
+	 * Invoke kmsg_dump (e.g., pstore) before crash_fadump() as fadump
+	 * runs before panic()'s kmsg_dump_desc() call.
+	 */
+	if (should_fadump_crash())
+		kmsg_dump_desc(KMSG_DUMP_PANIC, (char *)ptr);
+
 	/*
 	 * If firmware-assisted dump has been registered then trigger
 	 * its callback and let the firmware handles everything else.

Signature · 1 line

2.53.0

Sourabh Jain

Reviewed-by on v2 1/1

2026-04-13 05:23 UTC #1 lore raw

Quoted 55 lines · Shivang Upadhyay

fadump is registered in panic_notifier_list and gets triggered before kmsg_dump_desc() in the panic path. As a result, kmsg_dumpers such as pstore are not executed during fadump crashes.
This is problematic because pstore provides a critical fallback mechanism for crash analysis. When fadump fails to successfully reboot the system or capture a dump, pstore logs may be the only available information from the crashed kernel. Without invoking kmsg_dump_desc() in the fadump path, we lose this valuable diagnostic data.
Invoke kmsg_dump_desc() from the fadump panic handler, but only when fadump is actually registered (checked via should_fadump_crash()). This ensures kmsg_dumpers are called without duplicating the call that occurs later in panic() when fadump is not active.
The call is placed before crash_fadump() to ensure logs are captured before the system attempts to trigger the firmware-assisted dump.
Cc Hari Bathini <[email protected]>
Cc Madhavan Srinivasan <[email protected]>
Cc Mahesh Salgaonkar <[email protected]>
Cc Michael Ellerman <[email protected]>
Cc Ritesh Harjani (IBM) <[email protected]>
Reported-by Shirisha G <[email protected]>
Suggested-by Sourabh Jain <[email protected]>
Signed-off-by Shivang Upadhyay <[email protected]>
---
Changelog:
v2:
address comments from Sourabh, and sashikio-ai
added should_fadump_crash()
v1:
   https://lore.kernel.org/all/[email protected]/
---
  arch/powerpc/kernel/setup-common.c | 8 ++++++++
  1 file changed, 8 insertions(+)
arch/powerpc/kernel/setup-common.c +1 -0
index b1761909c23f..87afc8003a03 100644
@@ -68,6 +68,7 @@
  #include <asm/kasan.h>
  #include <asm/mce.h>
  #include <asm/systemcfg.h>
+#include <linux/kmsg_dump.h>
 
  #include "setup.h"
 
@@ -744,6 +745,13 @@ static int ppc_panic_fadump_handler(struct notifier_block *this,
  	 */
  	hard_irq_disable();
 

arch/powerpc/kernel/setup-common.c static int ppc_panic_fadump_handler(struct notifier_block *this, · line 757

Quoted 10 lines

arch/powerpc/kernel/setup-common.c +7 -0

+	/*
+	 * Invoke kmsg_dump (e.g., pstore) before crash_fadump() as fadump
+	 * runs before panic()'s kmsg_dump_desc() call.
+	 */
+	if (should_fadump_crash())
+		kmsg_dump_desc(KMSG_DUMP_PANIC, (char *)ptr);
+
  	/*
  	 * If firmware-assisted dump has been registered then trigger
  	 * its callback and let the firmware handles everything else.

Changes look good to me.

Feel free to add:

Reviewed-by Sourabh Jain <[email protected]>

- Sourabh Jain

Shivang Upadhyay

author

2026-04-13 05:24 UTC #2 lore raw

Quoted 6 lines · Sourabh Jain

Changes look good to me.
Feel free to add:
Reviewed-by Sourabh Jain <[email protected]>
- Sourabh Jain

Thanks
~Shivang.

Mahesh J Salgaonkar

Reviewed-by on v2 1/1

2026-04-13 10:11 UTC #3 lore raw

In reply to Shivang Upadhyay

Quoted 52 lines · Shivang Upadhyay

fadump is registered in panic_notifier_list and gets triggered before kmsg_dump_desc() in the panic path. As a result, kmsg_dumpers such as pstore are not executed during fadump crashes.
This is problematic because pstore provides a critical fallback mechanism for crash analysis. When fadump fails to successfully reboot the system or capture a dump, pstore logs may be the only available information from the crashed kernel. Without invoking kmsg_dump_desc() in the fadump path, we lose this valuable diagnostic data.
Invoke kmsg_dump_desc() from the fadump panic handler, but only when fadump is actually registered (checked via should_fadump_crash()). This ensures kmsg_dumpers are called without duplicating the call that occurs later in panic() when fadump is not active.
The call is placed before crash_fadump() to ensure logs are captured before the system attempts to trigger the firmware-assisted dump.
Cc Hari Bathini <[email protected]>
Cc Madhavan Srinivasan <[email protected]>
Cc Mahesh Salgaonkar <[email protected]>
Cc Michael Ellerman <[email protected]>
Cc Ritesh Harjani (IBM) <[email protected]>
Reported-by Shirisha G <[email protected]>
Suggested-by Sourabh Jain <[email protected]>
Signed-off-by Shivang Upadhyay <[email protected]>
---
Changelog:
v2:
address comments from Sourabh, and sashikio-ai
added should_fadump_crash()
v1:
https://lore.kernel.org/all/[email protected]/
---
 arch/powerpc/kernel/setup-common.c | 8 ++++++++
 1 file changed, 8 insertions(+)
arch/powerpc/kernel/setup-common.c +1 -0
index b1761909c23f..87afc8003a03 100644
@@ -68,6 +68,7 @@
 #include <asm/kasan.h>
 #include <asm/mce.h>
 #include <asm/systemcfg.h>
+#include <linux/kmsg_dump.h>
 
 #include "setup.h"
 

arch/powerpc/kernel/setup-common.c static int ppc_panic_fadump_handler(struct notifier_block *this, · line 754

Quoted 10 lines

arch/powerpc/kernel/setup-common.c +7 -0

@@ -744,6 +745,13 @@ static int ppc_panic_fadump_handler(struct notifier_block *this,
 	 */
 	hard_irq_disable();
 
+	/*
+	 * Invoke kmsg_dump (e.g., pstore) before crash_fadump() as fadump
+	 * runs before panic()'s kmsg_dump_desc() call.
+	 */
+	if (should_fadump_crash())
+		kmsg_dump_desc(KMSG_DUMP_PANIC, (char *)ptr);
+

Looks good to me.

Reviewed-by Mahesh Salgaonkar <[email protected]>

Thanks,
-Mahesh.

Quoted 7 lines

arch/powerpc/kernel/setup-common.c +0 -0

 	/*
 	 * If firmware-assisted dump has been registered then trigger
 	 * its callback and let the firmware handles everything else.

Signature · 1 line

2.53.0

Signature · 1 line

Mahesh J Salgaonkar

Shirisha ganta

Tested-by on v2 1/1

2026-04-15 04:41 UTC #4 lore raw

In reply to Shivang Upadhyay

Quoted 32 lines · Shivang Upadhyay

fadump is registered in panic_notifier_list and gets triggered before kmsg_dump_desc() in the panic path. As a result, kmsg_dumpers such as pstore are not executed during fadump crashes.
This is problematic because pstore provides a critical fallback mechanism
for crash analysis. When fadump fails to successfully reboot the system
or capture a dump, pstore logs may be the only available information from
the crashed kernel. Without invoking kmsg_dump_desc() in the fadump path,
we lose this valuable diagnostic data.
Invoke kmsg_dump_desc() from the fadump panic handler, but only when fadump is actually registered (checked via should_fadump_crash()). This
ensures kmsg_dumpers are called without duplicating the call that occurs
later in panic() when fadump is not active.
The call is placed before crash_fadump() to ensure logs are captured before the system attempts to trigger the firmware-assisted dump.
Cc Hari Bathini <[email protected]>
Cc Madhavan Srinivasan <[email protected]>
Cc Mahesh Salgaonkar <[email protected]>
Cc Michael Ellerman <[email protected]>
Cc Ritesh Harjani (IBM) <[email protected]>
Reported-by Shirisha G <[email protected]>
Suggested-by Sourabh Jain <[email protected]>
Signed-off-by Shivang Upadhyay <[email protected]>

Quoted 1 line

---

Hi,
Tested this patch and dmesg-nvram file under /sys/fs/pstore is getting updated with this patch after triggering dump with fadump

without this patch:

# ls -ltrh
total 0
-r--r--r--. 1 root root 6.5K Apr  2 06:22 dmesg-nvram-1
-r--r--r--. 1 root root 2.6K Apr 15 00:07 powerpc-common-nvram-6
-r--r--r--. 1 root root 2.1K Apr 15 00:07 rtas-nvram-1
-r--r--r--. 1 root root  688 Apr 15 00:07 powerpc-ofw-nvram-5

With this patch:

# ls -ltrh
total 0
-r--r--r--. 1 root root 6.4K Apr 15
00:36 dmesg-nvram-1
-r--r--r--. 1 root root 2.6K Apr 15 00:37 powerpc-
common-nvram-6
-r--r--r--. 1 root root 2.1K Apr 15 00:37 rtas-nvram-1
-r-
-r--r--. 1 root root  688 Apr 15 00:37 powerpc-ofw-nvram-5

Please add
below tag

Tested-by Shirisha G <[email protected]>

Quoted 42 lines

Changelog:

v2:
address comments from Sourabh, and sashikio-ai
added should_fadump_crash()

v1:

https://lore.kernel.org/all/[email protected]/

---
 arch/powerpc/kernel/setup-common.c | 8 ++++++++
 1 file changed, 8 insertions(+)

arch/powerpc/kernel/setup-common.c +3 -0

index b1761909c23f..87afc8003a03 100644
@@ -68,6 +68,7 @@
 #include <asm/kasan.h>
 #include <asm/mce.h>
 #include <asm/systemcfg.h>
+#include <linux/kmsg_dump.h>
 
 #include "setup.h"

@@ -744,6 +745,13 @@ static int ppc_panic_fadump_handler(struct
 notifier_block *this,
 	 */
 	hard_irq_disable();
 
+	/*
+	 * Invoke kmsg_dump (e.g., pstore) before crash_fadump() as

fadump

arch/powerpc/kernel/setup-common.c +5 -0

+	 * runs before panic()'s kmsg_dump_desc() call.
+	 */
+	if (should_fadump_crash())
+		kmsg_dump_desc(KMSG_DUMP_PANIC, (char *)ptr);
+
 	/*
 	 * If firmware-assisted dump has been registered then trigger
 	 * its callback and let the firmware handles everything else.

Madhavan Srinivasan

maintainer Applied

2026-06-19 22:00 UTC #5 lore raw

In reply to Shivang Upadhyay

Quoted 11 lines · Shivang Upadhyay

fadump is registered in panic_notifier_list and gets triggered before kmsg_dump_desc() in the panic path. As a result, kmsg_dumpers such as pstore are not executed during fadump crashes.
This is problematic because pstore provides a critical fallback mechanism for crash analysis. When fadump fails to successfully reboot the system or capture a dump, pstore logs may be the only available information from the crashed kernel. Without invoking kmsg_dump_desc() in the fadump path, we lose this valuable diagnostic data.
[...]

Applied to powerpc/next.

[1/1] ppc/fadump: invoke kmsg_dump in fadump panic path

      https://git.kernel.org/powerpc/c/6ed8332639853b77329594a241eb99fc36d591a2

cheers