Re: [PATCH v2] printk: Use two irq_works instead per-CPU

[Petr Mladek <pmladek@suse.com>]

On Tue 2026-09-22 09:08:34, Sebastian Andrzej Siewior wrote:
> On 2026-09-14 16:34:12 [+0200], To linux-kernel@vger.kernel.org wrote:
> > In commit b845b517b5e37 ("printk: robustify printk") initially got its
> > delayed wake up which is today implemented via the irq_work. Back then
> > it was a variable which was assigned to 1 if a pending wake up was
> > waiting. This variable was checked on each timer tick. Therefore it
> > makes sense to assign a per-CPU variable with this task to avoid cache
> > line bouncing when each CPU reads the variable on each timer tick
> > simultaneously.
> 
> Sashiko complains here, https://sashiko.dev/#/patchset/20260914143412.1sMcp89V%40linutronix.de
> 
> | Does replacing the per-CPU irq_work items with global items introduce a
> | system-wide starvation vulnerability on PREEMPT_RT?
> | On PREEMPT_RT, IRQ_WORK_LAZY items are processed by a per-CPU irq_work thread
> | running at a low SCHED_FIFO priority.
> | If one CPU queues pending_wakeup_work or pending_output_work, the item is
> | added to its local lazy_list and marked as pending. If that CPU runs a
> | higher priority RT task for an extended period, the irq_work thread is starved.
> | Since the irq_work structs are now global, their IRQ_WORK_PENDING flag remains
> | set during this time. Any subsequent calls to irq_work_queue() on other CPUs
> | will fail to queue the work and drop the wakeup requests.
> | Could an RT workload on a single CPU starve the global printk/klogd mechanisms
> | for the entire system, degrading the isolation provided by the previous per-CPU
> | design?
> 
> while this is true, it is not limited to printk but any workload would
> starve in such a scenario. Also, for the per-CPU variant to make a
> difference, one would need to have a printk output on another CPU, which
> is not busy with long running RT tasks.
> Long term this is probably the "legacy" system as console drivers should
> transform into nbcon interface. Here this irq-work would be reduced the
> userland wake up while the printing would happen via the nbcon thread
> which also has a single irq_work queue.
> 
> I don't see a problem with this.

I agree with your explanation. I do not see this as a problem either.

Best Regards,
Petr