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

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

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.

Sebastian