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

[John Ogness]

On 2026-09-22, Petr Mladek <pmladek@xxxxxxxx> wrote:
>> 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.

I also agree with the explanation. This is not a new problem because
starvation was always possible. With nbcon we have the advantage that
if an "RT-loaded CPU" enters the emergency state, the backlog will be
flushed in atomic mode.

John