Re: [PATCH v2] irq_work: Fix use-after-free in irq_work_single on PREEMPT_RT

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

On 2026-08-19 12:44:57 [+0200], Jan Kiszka wrote:
> With this patch, arm 32-bit, and a single-core SoC, I got a noticeable
> slowdown of irq_work_sync. Reverting the patch resolves this. So I dug
> deeper, found out that things were even worse before [1], but even with
> that, I could still see up to 2 ticks delay per call. If you combine
> that with an unfortunate loop of irq_work_sync calls (mine is
> out-of-tree, but I see something even "worse" in bpf_mem_alloc_destroy),
> there is this impact.
> 
> While this patch is motivated by PREEMPT_RT, the condition to enter the
> modified branch are not limited to it:

It is not motivated by PREEMPT_RT. All the lazy-work has "this" problem.
It is just on RT most of the work is stuffed into the lazy queue.

> ... || !arch_irq_work_has_interrupt()
> 
> arch_irq_work_has_interrupt() is false on some archs, either always
> (very rare) or under certain conditions. On arm, it's false when
> is_smp() is false.
> 
> If we "only" need the synchronize_rcu() for PREEMPT_RT, should we limit
> it to that configuration? Or do we actually need otherwise as well?
> 
> And what could be done to accelerate irq_work_sync loops? Practically, a
> single synchronize_rcu() at the end could be enough, no?

Let me look into this again…

> 
> Jan

Sebastian