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

[Breno Leitao <leitao@debian.org>]

On Mon, Nov 02, 2026 at 11:28:45AM +0100, Petr Mladek wrote:
> >     The call does not go into console_flush_on_panic(), because kgdb_panic()
> >     calls that before the other CPUs are stopped. It does not go after
> >     machine_crash_shutdown() either: on TDX guests tdx_kexec_finish() zaps
> >     the shared PTEs there, and netconsole on a virtio NIC would touch that
> >     memory.
> 
> This is the 1st time I hear about it. Does it mean that netconsole
> should not be called after this point, please?
> 
> I wonder how this worked before the netconsole was converted to
> the NBCON API. I guess that it "worked" because there was neither
> printk() nor any explicit console flush after this point.

Maybe. Kgdb is being removed so, maybe we don't need it:

https://lore.kernel.org/all/20261028122124.GJ2668804@noisy.programming.kicks-ass.net/

> 
> >     A write_atomic() that hangs now keeps the machine from rebooting or from
> >     reaching the crash kernel.
> >     
> > --- a/kernel/crash_core.c
> > +++ b/kernel/crash_core.c
> > @@ -140,6 +140,13 @@ void __noclone __crash_kexec(struct pt_regs *regs)
> >  
> >  			crash_setup_regs(&fixed_regs, regs);
> >  			crash_save_vmcoreinfo();
> > +			/*
> > +			 * Flush the unsafe consoles with the other CPUs
> > +			 * stopped, before machine_crash_shutdown() tears
> > +			 * down what they may need.
> > +			 */
> > +			crash_smp_send_stop();
> 
> AFAIK, the crashdump currently shows all CPUs online. And
> the backtrace shows whatever they were doing last.
> 
> Stopping the CPUs earlier would change the existing behavior.
> And we would need to discuss this with crashdump maintainers.
> 
> Well, I know that stopping other CPUs makes it more safe.
> But is it strictly necessary? We did not stop the CPUs
> when the netconsole was handled by the legacy loop.

That is fair, I will keep the old/legacy behavior now.

> > +			nbcon_atomic_unsafe_only_flush();
> >  			machine_crash_shutdown(&fixed_regs);
> >  			crash_cma_clear_pending_dma();
> >  			machine_kexec(kexec_crash_image);
> > diff --git a/kernel/panic.c b/kernel/panic.c
> > index 91e48d33b7dbbd..e14b1b60828130 100644
> > --- a/kernel/panic.c
> > +++ b/kernel/panic.c
> > @@ -723,6 +723,9 @@ void vpanic(const char *fmt, va_list args)
> >  		panic_console_replay)
> >  		console_flush_on_panic(CONSOLE_REPLAY_ALL);
> >  
> > +	/* The other CPUs are stopped, flush the unsafe consoles too.
> > h /tmp/puf_post.sh kerneltest001.31.atn1 6791 atn1a &); (sh
> > /tmp/puf_post.sh kerneltest005.19.atn2 6792 atn2a &)
> 
> The last two lines are some mess ;-)

Damn, sorry, These are my testing hosts I was using to test this patch.

> 
> > /
> > +	nbcon_atomic_unsafe_only_flush();
> 
> This might be too early. Anyway, it is before printing the line:
> 
> 		pr_emerg("Rebooting in %d seconds..\n", panic_timeout);
> 
> 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.

100% agreed. At Meta, we check if kdump is working or not based on these
massages. Given kdump cannot work due to 100 of different issues, this
line is more important than kdump by all changes.

Let me play with your crazy idea and see how it goes.

Thanks for helping here,
--breno