Re: [PATCH] printk: fold consecutive duplicate messages

[John Ogness <john.ogness@linutronix.de>]

Hi Lin,

On 2026-09-21, Lin Junzhe <m18667909625@163.com> wrote:
> Real cases I have seen in the field and in bug reports:
>
> 1. GPU faults (nouveau): a misbehaving userspace program or a dying
>    GPU can trigger a stream of identical fault reports from the
>    in-tree nouveau driver, e.g. repeated "fifo: fault at ..." lines
>    while the offending context keeps being rescheduled. Similar
>    spam exists for other GPU drivers when a fence or scheduler
>    loop misbehaves.

There are several such "fault at" messages. However, the ones I looked
at have other printk messages following in the same context, so your
patch would not even help in these cases.

Please specify the exact message (file + line number) you are talking
about. Perhaps it would be enough to change it to use a printk
ratelimited variant.

> 2. Failing storage: a dying SATA disk produces endless identical
>    "ata1.00: failed command" / "ata1: SError" storms. This is a
>    classic dmesg flood that buries everything else on machines
>    with a serial console and no syslogd.

The "failed command" ata printk is also followed by further printk's, so
your patch would not help.

Please specify the exact message you are concerned about.

> 3. USB reset loops: a flaky cable or port makes the USB stack
>    repeatedly print the identical "usb X-Y: reset <speed> USB
>    device number N using <hcd>" line, sometimes for minutes.

I could not find this pattern. Please specify the exact message.

> 4. IRQ storms: an unhandled level-triggered interrupt prints the
>    identical "irq N: nobody cared" report for every retrigger
>    until the IRQ is disabled.

This message also follows with more messages, so your patch would not
help.

>> printk is NMI safe and lockless. It needs to remain so.
>
> Fully agreed, and thank you for the clear statement. My
> implementation takes a raw spinlock in vprintk_emit(), which
> violates exactly that invariant -- the in_nmi() guard only avoids
> the deadlock by disabling the feature where it would be most
> dangerous, which is not acceptable either.
>
> Given this, I see two options:
>
> a) I drop the patch entirely; or
>
> b) I rework the idea as lockless per-CPU/per-console state at the
>    console output layer (or on top of nbcon), so the printk
>    fast path stays lock- and NMI-safe.
>
> Please tell me whether (b) is worth exploring or whether the
> consensus is that deduplication belongs in userspace and (a) is
> the right outcome. Either way is fine with me.

I am against a patch that drops messages just because a format string
repeats. The _data_ is not the same and that is important (particularly
with your GPU and SATA examples).

I am also skeptical that these are real-world issues as all of your
examples (that I could find) had different printk messages following,
which would lead to no drops.

There is also the ratelimited variant of printk. If there are indeed
messages that are not useful and can flood the kernel log, perhaps those
messages should be either removed or ratelimited.

If such a feature were to exist, I would prefer it is implemented such
that:

1. A duplicate message means contents are identical (except for the
timestamp of course).

2. It is implemented using flows similar to LOG_CONT to be certain that
the message being dropped is really the next message.

3. Records could be extended to include a counter for how often they
repeat (so that deferred consoles can print the "repeated" line).

Honestly, I do not see a real value for this feature. In my experience,
even if a console is being flooded with messages, I still want all those
messages. If a console is unable to keep up with the flood of incoming
records, I need to use a faster console and/or reduce my console
loglevel. And if there really are printk messages that can flood the
kernel log and are useless when repeated output, they should be make to
use the once or ratelimited variants.

John