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

[Petr Mladek <pmladek@suse.com>]

On Wed 2026-11-04 12:24:06, John Ogness wrote:
> 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.

Just to explain. I reacted on the sentence:

    "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 wanted to point out that the recent reports about missing messages
from both act 8250 and netconsole were seen as regressions. And
we should try to make it behave as before.

But you are right that the there is a difference. The messages were
missing with:

  + UAW 8250 because of bugs. All nbcon consoles relayed on kthreads
    in situations where they did not worked. We are solving this by
    explicitly switching to the atomic mode or by an explicit flush.

  + netconsole by design. The netconsole does not have a safe
    write_atomic() callback. We should allow unsafe takeover
    in some situations.

Now, the question is where to allow the unsafe takeover for
netconsole. I guess that we will need to allow it in similar
situations where people complained about DAR 8250 driver,
or pl011, e.g. even in emergency_restart().


> 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.

I think that I finally understand your concern. You would like to
add a per-console flag for "debugging" or "safe" mode. But
it might be weird when:

  + netconsole is in the "debugging" mode by default.

  + other serial consoles are in the "safe" mode by default.

Do I get it correctly, please?

> > 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.

I think that we should avoid people reporting regressions so that
we should allow unsafe takeover for the netconsole where reasonable
by default.

I see two solutions:

   1. Keep all NBCON consoles consistent and allow unsafe takeover
      on more locations, independently whether they have safe
      or unsafe write_atomic().

   2. Allow the unsafe takeover on more locations only for netconsole.
      And later allow to set both per-console policies: "debugging" vs. "safe".
      And accept that netconsole has different default policy.

I personally prefer the 2nd solution. Netconsole has always been
a bit special. And maybe someone would implement the safe write_atomic
in the future which will make it more normal, ...

Best Regards,
Petr