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:
>> *** WARNING: Now we get into my brainstorming, which could be rough. ***
>> 
>> Rather than a big hammer option, I see this more as a per-console
>> configuration (similar to how we want to go with the console loglevels).
>> 
>> Netconsole is a bit tricky, because it has its own format separate from
>> console. This would need to be addressed for the per-console loglevels
>> as well. Maybe it should be extended to something like:
>> 
>> netconsole=[+][r][src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr][,options]
>> 
>> Which would allow things like:
>> 
>> netconsole=@/,@10.10.0.2/,loglevel:3,unsafe_panic:1
>
> This cannot be per target, given that netconsole has multiple targets
> (as remote hosts/IPs), but a single registered console.

Well, actually there are two. I can setup a target using extended=0 and
another using extended=1 and then I see both "netconsole hubs": netcon0
and netcon_ext0.

> As of right now, all targets share the same remote, and would have the
> same unsafe_panic priority.

s/all targets/all targets of the same mode/

As you mentioned in the replay thread [0], maybe we should consider
registering a console for each target. I would expect that may even
simplify the "netconsole hub" dance that the netconsole code is
currently doing.

This change should not require any changes to existing netconsole
usage. AFAICT the differences would only be visible in
/proc/consoles. The advantage would be that each target could be
additionally individually configured using the generic
/sys/class/consoles interface for general features like:

loglevel, sync, replay, unsafe_panic

I am not suggesting removing the /sys/kernel/config/netconsole
interface. That works well for setting up the netconsoles. (Although
"extended" should then also migrate (or symlink) to the generic
per-console interface.) The /sys/class/consoles interface is
supplemental for the general console features (and maybe both could
provide symlinks to the other).

>> This would also allow to specify that consoles should _not_
>> perform unsafe flushing:
>> 
>> console=ttyS0,115200,unsafe_panic:0
>> 
>> And it could be used for ordering, flusing from highest value to lowest:
>> 
>> netconsole=@/,@10.10.0.2/,unsafe_panic:2 console=ttyS0,115200,unsafe_panic:12
>> 
>> (First ttyS0 is unsafe-flushed, then the netconsole is unsafe-flushed.)
>> 
>> 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.

By explicitly providing an unsafe ordering, the user could specify the
order of the consoles where the backlog is flushed unsafely. That
ordering may be based on probable reliability (maybe the chances of an
unsafe netconsole flush hanging are less than the chances of an unsafe
serial console flush hanging) or priority (if I only get 1 flush, then I
want it with the netconsole, so try it first).

And the feature could also be used to disable unsafe flushing so that a
particular console _never_ unsafe flushes (maybe the unsafe flushing
with a particular console driver is guaranteed fireworks, so it should
be avoided).

John

[0] https://lore.kernel.org/lkml/auDETo3ot3enCEv_@gmail.com/