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

[Petr Mladek]

On Mon 2026-11-02 23:28:27, John Ogness wrote:
> On 2026-11-02, Petr Mladek <pmladek@xxxxxxxx> wrote:
> > I have a crazy idea and do this:
> >
> > --- a/kernel/printk/nbcon.c
> > +++ b/kernel/printk/nbcon.c
> > @@ -1688,7 +1688,20 @@ static void __nbcon_atomic_flush_pending(u64 stop_seq)
> >   */
> >  void nbcon_atomic_flush_pending(void)
> >  {
> > -	__nbcon_atomic_flush_pending(prb_next_reserve_seq(prb));
> > +	u64 stop_seq = prb_next_reserve_seq(prb);
> > +
> > +	__nbcon_atomic_flush_pending(stop_seq, false);
> > +
> > +	/*
> > +	 * This is a compromise. Otherwise, NBCON consoles would never
> > +	 * have a chance to show messages in the panic paths where
> > +	 * the unsafe flush is not explicitely called.
> > +	 */
> > +	if (panic_on_this_cpu() && oops_in_progress) {
> > +		panic_nbcon_allow_unsafe_takeover = true;
> > +		__nbcon_atomic_flush_pending(stop_seq, true);
> > +		panic_nbcon_allow_unsafe_takeover = false;
> > +	}
> >  }
> >
> > It would allow to flush the messages directly by printk().
> >
> > I know that it would be a step back in the reliability. But showing
> > the messages looks more important to me than a reliable reboot.
> > And we could make it configurable when needed.
> >
> > Also we could add more checks. For example, do the unsafe flush only
> > when "num_online_cpus == 1" or so.
> 
> 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.


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.

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.

How does that sound, please?

Best Regards,
Petr