From: Lin Junzhe <m18667909625@163.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: linux-kernel@vger.kernel.org
Cc: m18667909625@163.com
Subject: Re: [PATCH] printk: fold consecutive duplicate messages
Date: Mon, 21 Sep 2026 22:40:00 +0800 [thread overview]
Message-ID: <20260921224000.1-m18667909625@163.com> (raw)
In-Reply-To: <87ik3yssy0.fsf@jogness.linutronix.de>
Hi John,
Thanks for the detailed follow-up, and for taking the time to check
each of my examples against the actual source.
You are right on all counts. In every case I cited, the repeated
format string is interleaved with other messages, so a "consecutive
duplicate" check would not have helped. More fundamentally, your
point that "same format string does not mean same data" exposes a
real flaw in my implementation: the dedup key hashes only the fmt
pointer and facility/level, not the arguments (a va_list can only be
consumed once), so two messages with different argument values would
be wrongly folded. That alone makes the patch incorrect for exactly
the scenarios it was meant to address.
I also accept the broader point: a message that is spammy enough to
flood the console should be fixed at its source with a ratelimited
or once-per-event variant, rather than papered over in printk.
So I am withdrawing this patch:
https://lore.kernel.org/lkml/20260921050304.73440-1-m18667909625@163.com/
Thank you and Petr for the reviews -- the "printk must remain lockless
and NMI-safe" invariant, and the guidance on where a feature like this
would have to live (store phase, exact-content match, LOG_CONT-style
ordering) were valuable lessons.
Best regards,
Lin Junzhe
--
Assisted-by: AI coding assistant (disclosed per kernel AI guidelines)
next prev parent reply other threads:[~2026-09-21 12:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 5:03 林濬哲
2026-09-21 7:52 ` John Ogness
2026-09-21 10:30 ` Lin Junzhe
2026-09-21 12:13 ` John Ogness
2026-09-21 14:40 ` Lin Junzhe [this message]
2026-09-23 9:43 ` Petr Mladek
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=20260921224000.1-m18667909625@163.com \
--to=m18667909625@163.com \
--cc=john.ogness@linutronix.de \
--cc=pmladek@suse.com \
/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®