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

[Jan Kiszka]

On 19.08.26 12:52, Sebastian Andrzej Siewior wrote:
> 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.

I was suspecting that already, but the patch description still reads
rt-only.

> 
>> ... || !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…
> 

Thanks!

I was meanwhile considering to backport the synchronize_rcu accelerator
commit. Seems to be straightforward for 6.12, but older kernels need more...

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center