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

[Gustavo Luiz Duarte]

On 2026-09-16 15:08:44+02:00, Petr Mladek wrote:
> On Tue 2026-09-15 11:01:38, Ryan Roberts wrote:
> 
> > Netconsole registers with CON_NBCON_ATOMIC_UNSAFE, so its write_atomic()
> > callback is only usable during nbcon_atomic_flush_unsafe(). Previously
> > this was only called by vpanic() if panic_timeout=0 - i.e. if the system
> > was configured not to reboot on panic. So if the system was configured
> > to reboot on panic, netconsole would never receive the panic logs.
> > 
> > Move vpanic()'s emergency_restart() call to after the call to
> > nbcon_atomic_flush_unsafe() to solve this problem. The downside is that
> > potentially unsafe operations are now performed prior to
> > emergency_restart() which could theoretically reduce the chances of the
> > restart succeeding. But we are already in a panic situation so it could
> > be argued that everything is best effort already.
> 
> The panic() code is like walking on bumpy roads. It tries to be as
> safe as possible. IMHO, it has few important tasks:
> 
>   + show debug messages
>   + create crash dump (optional)
>   + safely reboot (optional)
> 
> The debug messages are important but some users might prioritize
> reboot over the debug messages. It helps when the panic() is rare
> (low likely race) and the system is quickly able to handle the load
> after the reboot.
> 
> This is why we put nbcon_atomic_flush_unsafe() only into the path
> which ends with an infinite loop.
> 
> > 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.
> 
> 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();
> 	}
> 
> 	/* Flush legacy consoles once allowed, even when dangerous. */
> 	if (legacy_allow_panic_sync)
> 		console_flush_all(false, &next_seq, &handover);
> }
> 
> But maybe, this is over engineered and we should just call
> nbcon_atomic_flush_unsafe() in console_flush_on_panic(), 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_flush_unsafe();
> 	}
> 
> 	/* Flush legacy consoles once allowed, even when dangerous. */
> 	if (legacy_allow_panic_sync)
> 		console_flush_all(false, &next_seq, &handover);
> }

Hi Ryan, are you still planning to send a non-RFC patch? If not, I'm
happy to take over and send a patch with Petr's suggestion.
We are seeing cases in production of panic logs not reaching netconsole
because of this.