Re: [PATCH tty 0/1] Make 8250 deferred MSR handling LAZY

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

Hi Greg, Jiri,

On 2026-08-28, John Ogness <john.ogness@linutronix.de> wrote:
> There was a report and follow-up discussion [0] about a problem
> using regular irq_work queuing on some platforms when entering
> cpuidle. To circumvent this problem, all irq_work for printk will
> become IRQ_WORK_LAZY [1].
>
> The 8250 console driver uses irq_work to defer MSR handling during
> atomic printing. This means it is vulnerable to the same problem if,
> for example, a WARN() is hit while entering cpuidle on one of the
> affected platforms.
>
> Avoid the problem for deferred MSR handling by changing
> console_msr_work to IRQ_WORK_LAZY.

Any chance of getting this into 7.3? A similar patch went into 7.3-rc3
for printk:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/printk?id=560f4deda32785e260056200f8bb911c475c5b88

Or do I need to send a v2 with an updated commit message? I could
rephrase it similar to the related printk commit. Something like this:

Change console_msr_work (defers MSR handling) to be IRQ_WORK_LAZY,
thus not raising an IRQ upon irq_work queuing. The irq_work is then
handled on the next kernel tick. This additional delay is acceptable
because the MSR handling also occurs in the an interrupt handler, if
mctrl is queried, and during console resume. Using IRQ_WORK_LAZY has
the benefit of not needing to raise an IRQ for each line of atomic
console printing when modem control is active.

On a side note, the Tegra20 and Tegra30 platforms can hang if an
irq_work IRQ is raised while entering cpuidle states. This problem
was reproducible by performing atomic printing while entering cpuidle.
So this change also provides a workaround for these platforms (as
long as they are not running tickless).

John Ogness