Re: [PATCH] printk: fold consecutive duplicate messages

[Petr Mladek <pmladek@suse.com>]

On Mon 2026-09-21 14:19:43, John Ogness wrote:
> 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.

I have nothing more to say. I fully agree with John here.

Best Regards,
Petr