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.

[0] https://lore.kernel.org/lkml/f3757a75-0ba1-4558-bf57-f19ab7e59a4c@nvidia.com
[1] https://lore.kernel.org/lkml/20260828140218.232439-1-john.ogness@linutronix.de

John Ogness (1):
  serial: 8250: Change console_msr_work to IRQ_WORK_LAZY

 drivers/tty/serial/8250/8250_port.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


base-commit: 45c13f3f9e3bb15fd89ff2864c6f627a3b4b4229
-- 
2.47.3

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

On Mon, Sep 21, 2026 at 12:07:46PM +0206, John Ogness wrote:
> 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).

An updated changelog would be great, then I can take it for 7.3-final
easier.

thanks,

greg k-h