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

[Breno Leitao <leitao@debian.org>]

On Fri, Oct 23, 2026 at 12:36:15PM +0200, Petr Mladek wrote:
> On Fri 2026-10-23 10:03:47, John Ogness wrote:
> > Sorry for the late response... this fell through the cracks. Response
> > below...
> > 
> > On 2026-09-16, Petr Mladek <pmladek@suse.com> wrote:
> > >> In older kernels (v6.19 and earlier) netconsole is able to print these
> > >> panic logs while the system is configured to reboot on panic. So from a
> > >> user perspective this is a regression caused by commit 7eab73b18630
> > >> ("netconsole: convert to NBCON console infrastructure").
> > >> 
> > >> We have automated test systems without BMC access, which rely on these
> > >> two features working together.
> > >
> > > I see. To be precise, I would say that the primary culprit is the
> > > commit 187de7c212e5fa87 ("printk: nbcon: Allow unsafe write_atomic()
> > > for panic"). It adds support for consoles which will be flushed
> > > in panic() only by nbcon_atomic_flush_unsafe().
> > >
> > > It is a big difference because printk() tries to flush both
> > > legacy and "safe" NBCON consoles directly in panic(). In addition,
> > > they are explicitely flushed by console_flush_on_panic().
> > >
> > > console_flush_on_panic() is called more times in panic().
> > > And it tries to flush legacy consoles the unsafe way even
> > > before emergency_restart().
> > >
> > > OK, we should close this gap. But I suggest another solution.
> > >
> > > We already have the following functions for flushing NBCON
> > > consoles using write_atomic()
> > >
> > >
> > >   + nbcon_atomic_flush_pending() - flush CON_NBCON consoles
> > > 	using con->write_atomic() but only when safe
> > >
> > >   + nbcon_atomic_flush_unsafe() - flush CON_NBCON consoles
> > > 	using con->write_atomic() and allow unsafe takeover.
> > >
> > > I suggest to add 3rd variant, for example:
> > >
> > >   + nbcon_atomic_unsafe_flush_unsafe() - flush
> > > 	CON_NBCON_ATOMIC_UNSAFE consoles with con->write_atomic()
> > > 	and allow unsafe takeover.
> > 
> > nbcon_atomic_flush_unsafe() already includes CON_NBCON_ATOMIC_UNSAFE.
> 
> I was not clear enoungh. The purpose of the 3rd variant was
> to allow the unsafe takeover only for consoles with
> CON_NBCON_ATOMIC_UNSAFE. And rely only on the safe atomic flush
> for consoles which support it.
> 
> But it is likely too complicated and probably not worth it.
> 
> 
> > > And I would call this 3rd variant in console_flush_on_panic(),
> > > something like:
> > >
> > > void console_flush_on_panic(enum con_flush_mode mode)
> > > {
> > > [...]
> > > 	printk_get_console_flush_type(&ft);
> > > 	if (ft.nbcon_atomic) {
> > > 		nbcon_atomic_flush_pending();
> > > 		nbcon_atomic_unsafe_flush_unsafe();
> > 
> > s/nbcon_atomic_unsafe_flush_unsafe/nbcon_atomic_flush_unsafe/
> 
> Yes, I am fine with this.

This fixes the reboot case, since console_flush_on_panic() runs before
emergency_restart(). 

But I got the feeling that it does not help when a crash kernel is
loaded, which is a common production setup, and how our fleet runs.

With kdump, the kernel kexecs before any of the console_flush_on_panic()
calls in panic():

 1) panic() calls __crash_kexec() before panic_other_cpus_shutdown(),
    or right after kmsg_dump() with crash_kexec_post_notifiers.

 2) On an oops, oops_end() (x86) and die() (arm64) call crash_kexec()
    directly when kexec_should_crash() says so (panic_on_oops, oops in
    interrupt, ...), so panic() never runs. With
    crash_kexec_post_notifiers they go through panic() and hit 1).

So netconsole, or any CON_NBCON_ATOMIC_UNSAFE console, prints nothing
on kdump hosts.