Re: [RFC PATCH v1] panic: Flush unsafe consoles before panic reboot

[John Ogness <john.ogness@linutronix.de>]

On 2026-11-03, Petr Mladek <pmladek@suse.com> wrote:
>> I can accept this, since legacy-netconsole had these risks anyway. My
>> only concern is when we add an interface for the unsafe flushing policy,
>> will we continue to have unsafe flushing be the default for netconsole?
>> I guess we would need to keep it the same to avoid regressions (just as
>> we need to have it on by default now).
>
> Good point. I think that this basically goes down to the question
> whether we would later introduce an option:
>
>    --panic-focus-on-debug   or   --panic-focus-on-reboot
>
> The current state is somewhere in the middle. I would say
> that:
>
>   + the legacy consoles are more focusing on the debugging side
>     because bust_spinlocks() is called early. And
>     console_flush_on_panic() is called before emergency_restart().
>
>   + the nbcon console are more focusing on safe reboot because
>     nbcon_atomic_flush_unsafe() is called only when followed
>     by an infinite diod blinking.

Note that this difference between legacy and nbcon was one of the
primary design goals for nbcon. It is not chance that we are avoiding
"hope and pray mode".

> It looked like the nbcon handling was good enough before
> we added netconsole with an unsafe write_atomic. And maybe
> even before converting the widely used uart 8250 serial
> console driver.
>
> People started complaining about missing messages with
> the converted netconsole and uart 8250 drivers. The current
> nbcon handling looks like a regression to these people.

Please let's not throw everything into the same pot. The reported
missing 8250 messages are real regressions due to missing flushes. These
must be fixed.

The netconsole issue is separate. Unlike 8250, the netconsole does not
provide a safe variant. This is also a regression, but for different
reasons.

And maybe users want safe drivers (such as 8250) to enter "hope and pray
mode" on kernel ending sites, which is something even legacy consoles
could not always do.

> My take would be to modify the nbcon handling to be more
> like the legacy one and focus more on debugging. If anyone
> gets concerned by the reboot reliability then we
> could add the --panic-focus-on-reboot and make
> the reboot more safe in this case.

I prefer we do not hard-code policies. It would be trivial to add a
policy field and flags to the console struct. We could allow drivers to
declare their own diverging defaults if they want. When we are touching
all these flush sites, let us add code guided by policy instead of
hard-coding policy.

And _later_, once we have /sys/class/consoles, it becomes trivial to
expose these policies to userspace for reading/modifying.

John