From: Ryan Roberts <ryan.roberts@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Petr Mladek <pmladek@suse.com>,
Steven Rostedt <rostedt@goodmis.org>,
John Ogness <john.ogness@linutronix.de>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Rio <rioo.tsukatsukii@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1] panic: Flush unsafe consoles before panic reboot
Date: Tue, 15 Sep 2026 11:06:12 +0100 [thread overview]
Message-ID: <2710a283-aee2-495b-b941-3868f4461d6e@arm.com> (raw)
In-Reply-To: <20260915100140.3631650-1-ryan.roberts@arm.com>
On 15/09/2026 11:01, Ryan Roberts wrote:
> Netconsole registers with CON_NBCON_ATOMIC_UNSAFE, so its write_atomic()
> callback is only usable during nbcon_atomic_flush_unsafe(). Previously
> this was only called by vpanic() if panic_timeout=0 - i.e. if the system
> was configured not to reboot on panic. So if the system was configured
> to reboot on panic, netconsole would never receive the panic logs.
>
> Move vpanic()'s emergency_restart() call to after the call to
> nbcon_atomic_flush_unsafe() to solve this problem. The downside is that
> potentially unsafe operations are now performed prior to
> emergency_restart() which could theoretically reduce the chances of the
> restart succeeding. But we are already in a panic situation so it could
> be argued that everything is best effort already.
>
> In older kernels (v6.19 and earlier) netconsole is able to print these
> panic logs while the system is configured to reboot on panic. So from a
> user perspective this is a regression caused by commit 7eab73b18630
> ("netconsole: convert to NBCON console infrastructure").
>
> We have automated test systems without BMC access, which rely on these
> two features working together.
>
> Fixes: 7eab73b18630 ("netconsole: convert to NBCON console infrastructure")
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
Oops forgot to add commentary to the bottom:
I've set this as RFC because I'm not sure if the current behaviour is a
deliberate design decision? I guess if we flush the unsafe console, there is a
possibility it deadlocks, preventing the subsequent reboot. If people are
concerned about this, perhaps this needs a cmdline flag?
Thanks,
Ryan
> kernel/panic.c | 35 ++++++++++++++++++-----------------
> 1 file changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 213725b612aa..473dc7d13b23 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -732,32 +732,22 @@ void vpanic(const char *fmt, va_list args)
> mdelay(PANIC_TIMER_STEP);
> }
> }
> - if (panic_timeout != 0) {
> - /*
> - * This will not be a clean reboot, with everything
> - * shutting down. But if there is a chance of
> - * rebooting the system it will be rebooted.
> - */
> - if (panic_reboot_mode != REBOOT_UNDEFINED)
> - reboot_mode = panic_reboot_mode;
> - emergency_restart();
> - }
> + if (panic_timeout == 0) {
> #ifdef __sparc__
> - {
> extern int stop_a_enabled;
> /* Make sure the user can actually press Stop-A (L1-A) */
> stop_a_enabled = 1;
> pr_emerg("Press Stop-A (L1-A) from sun keyboard or send break\n"
> - "twice on console to return to the boot prom\n");
> - }
> + "twice on console to return to the boot prom\n");
> #endif
> #if defined(CONFIG_S390)
> - disabled_wait();
> + disabled_wait();
> #endif
> - pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
> + pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
>
> - /* Do not scroll important messages printed above */
> - suppress_printk = 1;
> + /* Do not scroll important messages printed above */
> + suppress_printk = 1;
> + }
>
> /*
> * The final messages may not have been printed if in a context that
> @@ -767,6 +757,17 @@ void vpanic(const char *fmt, va_list args)
> console_flush_on_panic(CONSOLE_FLUSH_PENDING);
> nbcon_atomic_flush_unsafe();
>
> + if (panic_timeout != 0) {
> + /*
> + * This will not be a clean reboot, with everything
> + * shutting down. But if there is a chance of
> + * rebooting the system it will be rebooted.
> + */
> + if (panic_reboot_mode != REBOOT_UNDEFINED)
> + reboot_mode = panic_reboot_mode;
> + emergency_restart();
> + }
> +
> local_irq_enable();
> for (i = 0; ; i += PANIC_TIMER_STEP) {
> touch_softlockup_watchdog();
> --
> 2.43.0
>
next prev parent reply other threads:[~2026-09-15 10:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 10:01 Ryan Roberts
2026-09-15 10:06 ` Ryan Roberts [this message]
2026-09-15 18:49 ` Bradley Morgan
2026-09-16 7:44 ` Ryan Roberts
2026-09-16 14:58 ` Bradley Morgan
2026-09-16 13:08 ` Petr Mladek
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=2710a283-aee2-495b-b941-3868f4461d6e@arm.com \
--to=ryan.roberts@arm.com \
--cc=akpm@linux-foundation.org \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=rioo.tsukatsukii@gmail.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®