Re: [PATCH] printk: fold consecutive duplicate messages

[Lin Junzhe <m18667909625@163.com>]

Hi John,

Thanks for the review.

> Could you provide some examples of consoles being flooded with
> the same message? Doesn't sound like a real case to me.

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.

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.

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.

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

In all four cases the messages come from kernel-side ratelimits or
error paths that repeat at line rate, and on systems where the only
observable output is the kernel console (serial console, early boot,
netconsole), no userspace dedup exists to save the log.

> 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.

Best regards,
林濬哲

--
Assisted-by: AI coding assistant (disclosed per kernel AI guidelines)