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

[John Ogness]

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.

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.

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.

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

John