From: Petr Mladek <pmladek@suse.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Breno Leitao <leitao@debian.org>,
chris@chrisdown.name, Sam Crossley <samuelcrossley@gmail.com>,
Thomas Gleixner <tglx@kernel.org>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Paolo Abeni <pabeni@redhat.com>,
Randy Dunlap <rdunlap@infradead.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Shuah Khan <skhan@linuxfoundation.org>,
Simon Horman <horms@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH RFC 0/2] netconsole: allow replaying the printk buffer on demand
Date: Mon, 26 Oct 2026 15:58:08 +0100 [thread overview]
Message-ID: <at9qgBucVm-QHnye@pathway.suse.cz> (raw)
In-Reply-To: <87a4o0k3qa.fsf@jogness.linutronix.de>
On Mon 2026-10-26 14:15:49, John Ogness wrote:
> On 2026-10-26, Breno Leitao <leitao@debian.org> wrote:
> >> In the per-console loglevel series Chris Down introduces [2]
> >> /sys/class/console/ to sysfs. This is where we would put all the
> >> upcoming per-console knobs. I would expect a replay trigger would fit
> >> well there.
> >
> > That makes sense from a design perspective. Thanks for the direction.
> >
> > So the next step would be to add a basic /sys/class/console/, similar to
> > [2], and put a `revplay` entry in it.
> >
> >
> > That would be about three patches:
> >
> > 1. Create /sys/class/console/, similar to [2] but without any loglevel
> > handling. cdown can build on it when respinning the loglevel series.
> > 2. Add the per-console replay helper, similar to [3].
> > 3. Add the first entry (/sys/class/console/replay), which triggers the
> > helper from patch 2.
> >
> > Is that what you have in mind?
Sounds good to me.
> Yes. But perhaps someone else wants to provide some feedback about this?
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.
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.
Best regards,
Petr
> >> [2] https://lore.kernel.org/lkml/84b8d91693e56f6026271bc40553bcb6657ab24d.1764272407.git.chris@chrisdown.name/gy
> >
> > [3] https://lore.kernel.org/all/20261024-netcons-replay-upstream-v1-1-9613f38496e5@gmail.com/
next prev parent reply other threads:[~2026-10-26 14:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-24 23:06 Sam Crossley
2026-10-24 23:06 ` [PATCH RFC 1/2] printk: add per-console replay helper Sam Crossley
2026-10-24 23:06 ` [PATCH RFC 2/2] netconsole: add configfs trigger to replay printk buffer Sam Crossley
2026-10-26 9:34 ` [PATCH RFC 0/2] netconsole: allow replaying the printk buffer on demand John Ogness
2026-10-26 11:44 ` Breno Leitao
2026-10-26 13:09 ` John Ogness
2026-10-26 14:58 ` Petr Mladek [this message]
2026-10-26 16:33 ` John Ogness
2026-10-26 17:49 ` Breno Leitao
2026-10-26 14:39 ` Chris Down
2026-10-26 15:32 ` Breno Leitao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=at9qgBucVm-QHnye@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=andrew+netdev@lunn.ch \
--cc=chris@chrisdown.name \
--cc=corbet@lwn.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=john.ogness@linutronix.de \
--cc=kuba@kernel.org \
--cc=leitao@debian.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=samuelcrossley@gmail.com \
--cc=senozhatsky@chromium.org \
--cc=skhan@linuxfoundation.org \
--cc=tglx@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®