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

[Breno Leitao <leitao@debian.org>]

On Thu, Oct 29, 2026 at 10:26:23AM +0106, John Ogness wrote:
> 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.

Right, thanks for the explanation and the links. Here is my view right now:

1) Converting netconsole to NBCON caused an undesired "regression" for
   users who would prefer the messages go out, even if unsafely. (as
   Ryan and Meta)

2) It seems the proper solution for this will take a few cycles.

3) I would hate to leave users with this "regression" we have today.

Do you have any suggestion for something doable in the short term?

Would reverting netconsole's NBCON conversion, while we address the
dependnecies above, be an option?

Thanks,
--breno