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

[Petr Mladek]

On Thu 2026-10-29 14:59:59, John Ogness wrote:
> On 2026-10-29, Breno Leitao <leitao@xxxxxxxxxx> wrote:
> > Here is my view right now:
> >
> > 1) Converting netconsole to NBCON caused an undesired "regression" for
> >    users who would prefer the messages go out, even if unsafely. (as
> >    Ryan and Meta)
> 
> Legacy consoles were never truly synchronous. But, generally speaking,
> they were mostly synchronous in normal situations, which was good enough
> (and certainly more synchronous than the nbcon netconsole implementation
> today).
> 
> > 2) It seems the proper solution for this will take a few cycles.
> 
> Based on past experience, I agree.
> 
> > 3) I would hate to leave users with this "regression" we have today.
> 
> Agreed.
> 
> > Do you have any suggestion for something doable in the short term?
> 
> It depends on what is deemed acceptable. For example, we could introduce
> a Kconfig to always unsafe-flush when the kernel ends. This would be a
> fairly straight-forward change and require no changes from the user
> environment. Later we could add boottime/runtime configuration for this
> policy and make it per-console.

Honestly, I do not like much the kconfig option. IMHO, people would
want to change the behavior for debugging purposes. So that a
command line parameter would be better.

> If Kconfig changes are not acceptable, we could hardwire unsafe flushing
> only for the netconsole (rather than all consoles). This would be a bit
> ugly, but it would still help us to identify all the correct points to
> enforce a later boottime/runtime policy.

This looks like a good compromise from my POV. NBCON console drivers
with a safe con->write_atomic() have a good chance to flush messages
before crash_kexec(). But consoles with CON_NBCON_ATOMIC_UNSAFE could
be flushed on the unsafe way in panic().

It is basically the 3rd variant of the atomic flush which I described
at https://lore.kernel.org/all/ats4n8snmReT7Nc9@xxxxxxxxxxxxxxx/

We should think twice about the name so that we do not mix it
with need to nbcon_atomic_flush_unsafe(). I propose:

    nbcon_atomic_unsafe_flush_unsafe()

where "atomic_unsafe" commes from CON_NBCON_ATOMIC_UNSAFE.
Or we could emphasize the fact that it is only the atomic_unsafe
and use:

   nbcon_atomic_unsafe_only_flush()

and I would pass it via a parameter to

static void __nbcon_atomic_flush_pending(u64 stop_seq, bool unsafe_only)
{
	struct console *con;
	int cookie;

	cookie = console_srcu_read_lock();
	for_each_console_srcu(con) {
		short flags = console_srcu_read_flags(con);

		if (!(flags & CON_NBCON))
			continue;

+		if (unsafe_only && !(flags & CON_NBCON_ATOMIC_UNSAFE))
+			continue;
+
		if (!console_is_usable(con, flags, true))
			continue;

		if (nbcon_seq_read(con) >= stop_seq)
			continue;

		nbcon_atomic_flush_pending_con(con, stop_seq);
	}
	console_srcu_read_unlock(cookie);
}

Another question is where to call it. I guess the it should be called
in two code paths:

   + __crash_kexec() likely after stopping other CPUs

    + console_flush_on_panic() after flushing safe nbcon consoles
	the safe way

> I am open to both of these suggestions.
> 
> > Would reverting netconsole's NBCON conversion, while we address the
> > dependnecies above, be an option?
> 
> That would be unfortunate since the nbcon consoles provide a real
> benefit during runtime (full offloading of console printing). Also, the
> nbcon callbacks allowed the netconsole code to simplify due to the known
> in_task() context.

I agree. It would be great to keep the netconsole driver converted.

> And I would like to remind that our ultimate goal would be to establish
> safe atomic printing for the netconsole. So any workarounds (such as
> CON_NBCON_ATOMIC_UNSAFE) are only meant to be temporary (even if
> temporary will be measured in years).

Yeah, making this work a safe way would be a pretty challenging job.

Best Regards,
Petr