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

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

On 2026-10-28, Breno Leitao <leitao@debian.org> wrote:
>>>> For consoles with CON_NBCON_ATOMIC_UNSAFE, the default would be
>>>> unsafe_panic:0. Otherwise the default would be unsafe_panic:1.
>>>
>>> How do you plan to use 'unsafe_panic' order exactly?
>> 
>> Currently at the end of panic() an unsafe flush occurs by simply
>> iterating through the list of consoles. That list ordering does have a
>> fixed algorithm behind it, but it is quite hard to follow.
>
> But is that flush invoked at all on the kdump/kexec path?
>
> As far as I can see, nbcon_atomic_flush_unsafe() has a single caller,
> at the very end of vpanic(). So the unsafe consoles are only flushed in
> one specific "kernel ending" case: panic() with panic_timeout=0 and no
> crash kernel loaded.
>
> I think we are mixing two different topics here:
>
>    1) How to set the order of the unsafe flush (per console, from the
>       cmdline and/or sysfs).
>
>    2) A hook at the "kernel ending" sites (the panic reboot path,
>       __crash_kexec(), ...), so we do not forget to flush the unsafe
>       consoles there.
>
> Should we split them? 
>
> The missing hook in 2) is what drops the netconsole panic output today,
> while 1) is policy on top of it.

They are separate but related. We need to address the missing hooks. But
we cannot simply add unsafe flushing to those hooks. We need to allow
policy for that.

First we need to make sure all "kernel ending" points are doing proper
atomic (safe!) flushing. Ideally these are either graceful endings, so
the kthreads are properly shutdown and printk naturally transitions to
atomic printing. Or they are emergency situations and printk must
forcefully transition to atomic printing. (Netconsole does not yet
benefit from this, but we need to be sure that safe consoles are
covered.)

Then we need to add an interface to allow the user to specify policy for
the points to determine unsafe flushing. I would request that the
interface is such that we can extend it to allow ordering of that unsafe
flushing.

Note that the interface may involve some significant rework on how
netconsoles are managed.

This all needs to be coordinated with other things already in the queue
due to the overlap in code and features:

- preferred console cleanup/refactor [0]

- CON_ENABLE cleanup [1]

- introduction of per-console loglevels [2]

- per-console replaying [3]

I am not suggesting that all these things must come first, but we need
to keep an eye on the big picture rather than hacking in some quick
workarounds for netconsole.

John

[0] https://lore.kernel.org/lkml/20260929120546.328616-1-pmladek@suse.com
[1] https://lore.kernel.org/lkml/20251227-printk-cleanup-part3-v1-0-21a291bcf197@suse.com
[2] https://lore.kernel.org/lkml/cover.1764272407.git.chris@chrisdown.name
[3] https://lore.kernel.org/lkml/20261024-netcons-replay-upstream-v1-0-9613f38496e5@gmail.com