All of lore.kernel.org
 help / color / mirror / Atom feed
From: Breno Leitao <leitao@debian.org>
To: John Ogness <john.ogness@linutronix.de>
Cc: Petr Mladek <pmladek@suse.com>,
	Ryan Roberts <ryan.roberts@arm.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	 Sergey Senozhatsky <senozhatsky@chromium.org>,
	Rio <rioo.tsukatsukii@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1] panic: Flush unsafe consoles before panic reboot
Date: Wed, 28 Oct 2026 04:24:09 -0700	[thread overview]
Message-ID: <auHUCbBOJjBwk-ml@gmail.com> (raw)
In-Reply-To: <87v76n2fb9.fsf@jogness.linutronix.de>

On Tue, Oct 27, 2026 at 07:07:30PM +0106, John Ogness wrote:
> On 2026-10-27, Breno Leitao <leitao@debian.org> wrote:
> > On Tue, Oct 27, 2026 at 09:12:09AM -0700, Breno Leitao wrote:

> Perhaps we need to begin by identifying all the sites where the current
> kernel is ending (whether reboot, shutdown, panic, kexec, hang).

Ack. This is what I have so far on the panic side:

 1) panic() ending in the final loop (panic_timeout=0): flushed at the
    end, including the unsafe consoles (d988d9a9b9d180, 5dde3b735413).

 2) panic() ending in emergency_restart(): no unsafe flush (Ryan's RFC).

 3) panic() ending in __crash_kexec(): the console_flush_on_panic() and
    nbcon_atomic_flush_unsafe() calls all come later, with or without
    crash_kexec_post_notifiers.

 4) An oops ending in crash_kexec() straight from oops_end()/die(),
    when kexec_should_crash() is true. panic() never runs.

 5) Other crash_kexec() callers, such as s390 and hypervisors.

> > +                       /* Flush consoles with an unsafe write_atomic(), e.g. netconsole. */
> > +                       nbcon_atomic_flush_unsafe();
>
> I am guessing that the CPU is _always_ in emergency state here?
> Otherwise the flushing problem exists for all atomic consoles.

True. But for the unsafe consoles, the end of panic() already handles
this.

d988d9a9b9d180 ("panic: Flush kernel log buffer at the end") added
a final console_flush_on_panic(), and 5dde3b735413 ("printk: nbcon: Add
unsafe flushing on panic") added nbcon_atomic_flush_unsafe() after it,
to make sure the last messages get out.

That _only_ runs when panic() ends in the final loop, though. kdump never
gets there, and neither does reboot-on-panic or, possibly, some of the
other "kernel ending" sites you mentioned above.

The kdump case is the one I care about most. It is a regression for us
(Meta) in production, where kdump is always armed: netconsole has lost
these messages since it moved to nbcon.

So far we have identified two places that need the same unsafe flush
that 5dde3b735413 added to the final loop:

 a) panic() ending in emergency_restart(). Petr's suggestion to flush
    from console_flush_on_panic() covers this one.

 b) __crash_kexec(), reached from panic() or straight from
    oops_end()/die().

  reply	other threads:[~2026-10-28 11:24 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 10:01 [RFC PATCH v1] panic: Flush unsafe consoles before panic reboot Ryan Roberts
2026-09-15 10:06 ` Ryan Roberts
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
2026-10-22 20:35   ` Gustavo Luiz Duarte
2026-10-23  7:57   ` John Ogness
2026-10-23 10:36     ` Petr Mladek
2026-10-27 16:12       ` Breno Leitao
2026-10-27 17:43         ` Breno Leitao
2026-10-27 18:01           ` John Ogness
2026-10-28 11:24             ` Breno Leitao [this message]
2026-10-28 10:52     ` Breno Leitao
2026-10-28 14:37       ` John Ogness
2026-10-28 21:15         ` Breno Leitao
2026-10-29  9:20           ` John Ogness
2026-10-29 10:58             ` Breno Leitao
2026-10-29 13:53               ` John Ogness
2026-10-29 14:37                 ` Petr Mladek
2026-10-30 17:56                   ` Breno Leitao
2026-11-02 10:28                     ` Petr Mladek
2026-11-02 13:27                       ` Breno Leitao
2026-11-02 22:22                       ` John Ogness
2026-11-03 13:31                         ` Petr Mladek
2026-11-04 11:18                           ` John Ogness
2026-11-05 16:50                             ` Petr Mladek
2026-11-05 19:01                               ` John Ogness
2026-11-02 22:14                     ` John Ogness

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=auHUCbBOJjBwk-ml@gmail.com \
    --to=leitao@debian.org \
    --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=ryan.roberts@arm.com \
    --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 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.