Re: [PATCH RFC 0/2] netconsole: allow replaying the printk buffer on demand

[John Ogness]

On 2026-10-26, Petr Mladek <pmladek@xxxxxxxx> wrote:
> The "replay" approach looks like a big hammer. Many messages might get
> duplicated, especially when the outage was small.
>
> A better solution might be to do not increment con->nbcon_seq
> when the transmission failed. And try it later again.

Note that there was a time during the rework that we used to allow the
console to return failure but decided it was too complicated [0].

The kthreads are setup to stay in their printing loop until the backlog
is clear. Having a nice=-20 task busy-loop would be bad.

> con->write_thread() currently does not return anything. I believe that
> it is partly a historical limit. Two problems come to my mind:
>
>    1. There used to be a global "console_seq" counter which was common
>       for all console drivers. But we have a per-console counter since
>       the commit a699449bb13b70b8bd1 ("printk: refactor and rework
>       printing logic").
>
>    2. There has never been a try-later logic. But is should be easier
>       to add it now. We have the kthreads. And even the legacy loop
>       is able to break when there is not progress.

I suppose for only the write_thread() callback we could implement some
sort of throttled retry if the console driver reports failure. But this
is assuming console drivers can even detect if it successfully sent or
not. The netconsole certainly has no method to _know_ if the UDP packet
was received. And UARTs (asside from flow-control) also have no way to
confirm that the other side received the data.

Breno and Sam simply want the user to trigger a replay of the full
log. Essentially a sysrq-R but per-console. I think that is a reasonable
request and certainly much easier than attempting some sort of
transmission guarantee.

John

[0] https://lore.kernel.org/lkml/ZdTCZqhZww8_WgSU@alley