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

[Breno Leitao]

On Mon, Oct 26, 2026 at 05:39:54PM +0106, John Ogness wrote:
> 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.

A bit of context on the use case from our side.

In an ideal world netconsole is enabled from early boot through the
kernel command line, but in some case this is impossible
(linux as bootloaders - ipxe/sd-stubs/etc).

The other way to setup netconsole is to create a new target at runtime
through configfs. Netconsole then only sends messages from the time the
target is enabled.

For this second case, I would like to replay the whole kernel log on
netconsole, such as previous messages. Something might have happened
before the target was enabled, and we want visibility into that.

That said, the "per-console counter" might work as well, since it would
start as 0, thus, we know that netconsole target would be behind, and
try to replay? (not sure how yet)

That said, one way or another might work for our purposes ?!

Thanks for the proposal and discussions,
--breno