From: sashiko-bot@kernel.org
To: "Mete Durlu" <meted@linux.ibm.com>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>
Subject: Re: [PATCH v5 2/3] s390: Implement arch_do_panic()
Date: Mon, 10 Aug 2026 11:44:50 +0000 [thread overview]
Message-ID: <20260810114451.4900A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260810-arch_do_panic-v5-2-e86ae992c253@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly introduced `arch_do_panic()` hook is placed before the final console flushes, which causes the 'end Kernel panic' marker to remain unflushed in deferred printk contexts on s390.
--
--- Patch [2]: [PATCH v5 2/3] s390: Implement arch_do_panic() ---
commit b9b01d12abb499c817ce8c2a246d404e0331bf81
Author: Mete Durlu <meted@linux.ibm.com>
s390: Implement arch_do_panic()
This commit introduces a s390-specific arch_do_panic() implementation, removing
an ifdef section from vpanic(). It moves the disabled_wait() call so it occurs
after the "end Kernel panic" marker is printed.
> diff --git a/arch/s390/kernel/traps.c b/arch/s390/kernel/traps.c
> index 564403496a7ce..309d3d3e95fd9 100644
> --- a/arch/s390/kernel/traps.c
> +++ b/arch/s390/kernel/traps.c
[ ... ]
> @@ -275,6 +277,11 @@ static void monitor_event_exception(struct pt_regs *regs)
> }
> }
>
> +void arch_do_panic(void)
> +{
> + disabled_wait();
> +}
> +
[Severity: Medium]
Will this prevent the final console flushes from executing on s390?
Looking at vpanic() in kernel/panic.c, arch_do_panic() is called before the
final console flushes:
pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
arch_do_panic();
/* Do not scroll important messages printed above */
suppress_printk = 1;
/*
* The final messages may not have been printed if in a context that
* defers printing (such as NMI) and irq_work is not available.
* Explicitly flush the kernel log buffer one last time.
*/
console_flush_on_panic(CONSOLE_FLUSH_PENDING);
nbcon_atomic_flush_unsafe();
Since disabled_wait() puts the CPU into an infinite wait state, it never
returns to vpanic(). If the panic occurs in a context that defers printk
(such as an NMI), does this mean the "end Kernel panic" marker will remain
unflushed and not visible on the console?
> void kernel_stack_invalid(struct pt_regs *regs)
> {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260810-arch_do_panic-v5-0-e86ae992c253@linux.ibm.com?part=2
next prev parent reply other threads:[~2026-08-10 11:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 11:35 [PATCH v5 0/3] Introduce arch_do_panic Mete Durlu
2026-08-10 11:35 ` [PATCH v5 1/3] panic: " Mete Durlu
2026-08-10 11:46 ` sashiko-bot
2026-08-10 11:35 ` [PATCH v5 2/3] s390: Implement arch_do_panic() Mete Durlu
2026-08-10 11:44 ` sashiko-bot [this message]
2026-08-10 12:01 ` Bradley Morgan
2026-08-10 12:35 ` Heiko Carstens
2026-08-10 11:35 ` [PATCH v5 3/3] sparc: Implement arch_do_panic Mete Durlu
2026-08-10 11:47 ` sashiko-bot
2026-08-10 12:11 ` Bradley Morgan
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=20260810114451.4900A1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=meted@linux.ibm.com \
--cc=sashiko-reviews@lists.linux.dev \
/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.