All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mahesh J Salgaonkar <mahesh@linux.ibm.com>
To: Shivang Upadhyay <shivangu@linux.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	maddy@linux.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com,
	chleroy@kernel.org, kees@kernel.org, tony.luck@intel.com,
	gpiccoli@igalia.com, ritesh.list@gmail.com, rppt@kernel.org,
	Hari Bathini <hbathini@linux.ibm.com>,
	Shirisha G <shirisha@linux.ibm.com>,
	Sourabh Jain <sourabhjain@linux.ibm.com>
Subject: Re: [PATCH v2] ppc/fadump: invoke kmsg_dump in fadump panic path
Date: Mon, 13 Apr 2026 15:41:01 +0530	[thread overview]
Message-ID: <ady_5OZe0t8AkFmM@linux.ibm.com> (raw)
In-Reply-To: <20260412113057.46090-1-shivangu@linux.ibm.com>

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


  parent reply	other threads:[~2026-04-13 10:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2026-04-15  4:41 ` Shirisha ganta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ady_5OZe0t8AkFmM@linux.ibm.com \
    --to=mahesh@linux.ibm.com \
    --cc=chleroy@kernel.org \
    --cc=gpiccoli@igalia.com \
    --cc=hbathini@linux.ibm.com \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=ritesh.list@gmail.com \
    --cc=rppt@kernel.org \
    --cc=shirisha@linux.ibm.com \
    --cc=shivangu@linux.ibm.com \
    --cc=sourabhjain@linux.ibm.com \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.