* Re: [PATCH v2] ppc/fadump: invoke kmsg_dump in fadump panic path
2026-04-12 11:30 [PATCH v2] ppc/fadump: invoke kmsg_dump in fadump panic path Shivang Upadhyay
@ 2026-04-13 5:22 ` Sourabh Jain
2026-04-13 5:23 ` Shivang Upadhyay
2026-04-13 10:11 ` Mahesh J Salgaonkar
2026-04-15 4:41 ` Shirisha ganta
2 siblings, 1 reply; 5+ messages in thread
From: Sourabh Jain @ 2026-04-13 5:22 UTC (permalink / raw)
To: Shivang Upadhyay, linuxppc-dev, linux-kernel
Cc: maddy, mpe, npiggin, chleroy, kees, tony.luck, gpiccoli,
ritesh.list, rppt, Hari Bathini, Mahesh Salgaonkar, Shirisha G
On 12/04/26 17:00, Shivang Upadhyay wrote:
> 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 <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Reported-by: Shirisha G <shirisha@linux.ibm.com>
> Suggested-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Signed-off-by: Shivang Upadhyay <shivangu@linux.ibm.com>
> ---
> Changelog:
>
> v2:
> address comments from Sourabh, and sashikio-ai
> added should_fadump_crash()
>
> v1:
> https://lore.kernel.org/all/20260407054341.308710-1-shivangu@linux.ibm.com/
> ---
> arch/powerpc/kernel/setup-common.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> index b1761909c23f..87afc8003a03 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -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.
Changes look good to me.
Feel free to add:
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
- Sourabh Jain
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] ppc/fadump: invoke kmsg_dump in fadump panic path
2026-04-12 11:30 [PATCH v2] ppc/fadump: invoke kmsg_dump in fadump panic path Shivang Upadhyay
2026-04-13 5:22 ` Sourabh Jain
@ 2026-04-13 10:11 ` Mahesh J Salgaonkar
2026-04-15 4:41 ` Shirisha ganta
2 siblings, 0 replies; 5+ messages in thread
From: Mahesh J Salgaonkar @ 2026-04-13 10:11 UTC (permalink / raw)
To: Shivang Upadhyay
Cc: linuxppc-dev, linux-kernel, maddy, mpe, npiggin, chleroy, kees,
tony.luck, gpiccoli, ritesh.list, rppt, Hari Bathini, Shirisha G,
Sourabh Jain
On 2026-04-12 17:00:57 Sun, Shivang Upadhyay wrote:
> 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 <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Reported-by: Shirisha G <shirisha@linux.ibm.com>
> Suggested-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Signed-off-by: Shivang Upadhyay <shivangu@linux.ibm.com>
> ---
> Changelog:
>
> v2:
> address comments from Sourabh, and sashikio-ai
> added should_fadump_crash()
>
> v1:
> https://lore.kernel.org/all/20260407054341.308710-1-shivangu@linux.ibm.com/
> ---
> arch/powerpc/kernel/setup-common.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
> index b1761909c23f..87afc8003a03 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -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);
> +
Looks good to me.
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Thanks,
-Mahesh.
> /*
> * If firmware-assisted dump has been registered then trigger
> * its callback and let the firmware handles everything else.
> --
> 2.53.0
>
>
--
Mahesh J Salgaonkar
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] ppc/fadump: invoke kmsg_dump in fadump panic path
2026-04-12 11:30 [PATCH v2] ppc/fadump: invoke kmsg_dump in fadump panic path Shivang Upadhyay
2026-04-13 5:22 ` Sourabh Jain
2026-04-13 10:11 ` Mahesh J Salgaonkar
@ 2026-04-15 4:41 ` Shirisha ganta
2 siblings, 0 replies; 5+ messages in thread
From: Shirisha ganta @ 2026-04-15 4:41 UTC (permalink / raw)
To: Shivang Upadhyay, linuxppc-dev, linux-kernel
Cc: maddy, mpe, npiggin, chleroy, kees, tony.luck, gpiccoli,
ritesh.list, rppt, Hari Bathini, Mahesh Salgaonkar, Sourabh Jain
On Sun, 2026-04-12 at 17:00 +0530, Shivang Upadhyay wrote:
> 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 <hbathini@linux.ibm.com>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Reported-by: Shirisha G <shirisha@linux.ibm.com>
> Suggested-by: Sourabh Jain <sourabhjain@linux.ibm.com>
> Signed-off-by: Shivang Upadhyay <shivangu@linux.ibm.com>
> ---
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 <shirisha@linux.ibm.com>
> Changelog:
>
> v2:
> address comments from Sourabh, and sashikio-ai
> added should_fadump_crash()
>
> v1:
>
> https://lore.kernel.org/all/20260407054341.308710-1-shivangu@linux.ibm.com/
> ---
> arch/powerpc/kernel/setup-common.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/powerpc/kernel/setup-common.c
> b/arch/powerpc/kernel/setup-common.c
> index b1761909c23f..87afc8003a03 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -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.
^ permalink raw reply [flat|nested] 5+ messages in thread