From: Heiko Carstens <hca@linux.ibm.com>
To: Mete Durlu <meted@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Petr Mladek <pmladek@suse.com>, Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
"David S. Miller" <davem@davemloft.net>,
Andreas Larsson <andreas@gaisler.com>,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org,
sparclinux@vger.kernel.org
Subject: Re: [PATCH v2 0/3] Introduce arch_do_panic
Date: Wed, 29 Jul 2026 10:56:55 +0200 [thread overview]
Message-ID: <20260729085655.17504C1f-hca@linux.ibm.com> (raw)
In-Reply-To: <20260727-arch_do_panic-v2-0-4e25ceb05075@linux.ibm.com>
On Mon, Jul 27, 2026 at 12:36:19PM +0200, Mete Durlu wrote:
> Changes in v2 - Address Sashiko findings;
> - Patch 2: Remove unused leftover code
> - Patch 2: Mention panic_timeout and shutdown_actions relationship for
> s390 in commit message
> - Patch 3: Use bug.h instead of setup.h to pass around arch_do_panic
> implementation of sparc
>
> Replace architecture-specific ifdef sections in vpanic() with a clean
> arch_do_panic() hook. Currently s390 and sparc embed their panic
> handlers directly in vpanic() using preprocessor conditionals, making
> the common code path harder to maintain.
>
> Introduce arch_do_panic() as an architecture extension point called at
> the end of vpanic(). Architectures can use this hook to implement their
> specific panic handling without polluting the generic panic code.
>
> Move s390 panic handling from the panic_notifier chain to
> arch_do_panic(). This corrects the execution order so that the
> panic_timeout is properly evaluated before architecture-specific
> actions. The previous notifier-based approach executed too early in the
> panic sequence.
>
> Move sparc panic handling from ifdef blocks to arch_do_panic(). Remove
> the preprocessor conditionals from vpanic() and place the Stop-A
> enablement code in architecture-specific files where it belongs.
>
> The cleanup reduces vpanic() complexity and establishes a pattern for other
> architectures needing custom panic behavior.
>
> Signed-off-by: Mete Durlu <meted@linux.ibm.com>
> ---
> Mete Durlu (3):
> panic: Introduce arch_do_panic
> s390: Implement arch_do_panic
> sparc: Implement arch_do_panic
>
> arch/s390/include/asm/setup.h | 3 +++
> arch/s390/kernel/ipl.c | 15 +--------------
> arch/sparc/include/asm/bug.h | 3 +++
> arch/sparc/include/asm/setup.h | 1 -
> arch/sparc/kernel/setup.c | 8 ++++++++
> kernel/panic.c | 18 ++++++------------
> 6 files changed, 21 insertions(+), 27 deletions(-)
Putting the define in a different header file per architecture doesn't
seem to be a good idea. There is no guarantee that this will work. So
either you find a common header file, where it is known that is (and
will be) included in panic.c, or you go with a weak function.
next prev parent reply other threads:[~2026-07-29 8:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-27 10:36 [PATCH v2 0/3] Introduce arch_do_panic Mete Durlu
2026-07-27 10:36 ` [PATCH v2 1/3] panic: " Mete Durlu
2026-07-27 10:43 ` sashiko-bot
2026-07-27 12:59 ` Bradley Morgan
2026-07-28 10:13 ` Mete Durlu
2026-07-27 10:36 ` [PATCH v2 2/3] s390: Implement arch_do_panic Mete Durlu
2026-07-27 10:52 ` sashiko-bot
2026-07-27 13:01 ` Bradley Morgan
2026-07-28 10:43 ` Mete Durlu
2026-07-28 11:02 ` Bradley Morgan
2026-07-28 11:40 ` Sven Schnelle
2026-07-28 11:43 ` Bradley Morgan
2026-07-27 10:36 ` [PATCH v2 3/3] sparc: " Mete Durlu
2026-07-27 10:49 ` sashiko-bot
2026-07-27 13:02 ` Bradley Morgan
2026-07-29 8:56 ` Heiko Carstens [this message]
2026-07-29 10:48 ` [PATCH v2 0/3] Introduce arch_do_panic Mete Durlu
2026-07-29 12:06 ` Heiko Carstens
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=20260729085655.17504C1f-hca@linux.ibm.com \
--to=hca@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=andreas@gaisler.com \
--cc=borntraeger@linux.ibm.com \
--cc=davem@davemloft.net \
--cc=gor@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=meted@linux.ibm.com \
--cc=pmladek@suse.com \
--cc=sparclinux@vger.kernel.org \
--cc=svens@linux.ibm.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.