Re: [QUESTION] Are these issues PREEMPT_RT-specific?

[Florian Bezdeka <florian.bezdeka@siemens.com>]

On Fri, 2026-09-04 at 16:11 +0800, Ran Hongyun wrote:
> The commit eb0d280c2751 ("eventpoll: Replace rwlock with spinlock") aims to fix:
> 
> 1.Priority inversion – On PREEMPT_RT, rwlock_t readers lack priority
> inheritance (PI), so a low-priority reader holding the lock can be
> preempted by a medium-priority task, blocking a high-priority writer
> indefinitely.
> 
> 2.Stall – A reader (p_read) holding the lock can be throttled by CFS
> bandwidth control and scheduled out. A writer (p_write) blocks waiting
> for the lock, and a timer thread (ktimers/n) needed to replenish p_read's
> runtime is blocked due to writer-fairness (286deb7ec03d). This forms a
> circular dependency and stalls the system.
> 
> Are these issues PREEMPT_RT-specific? 

No, but it's way more critical on PREEMPT_RT. !RT systems will see a
"performance" or "throughput" drop but not a critical system stall.

> 
> Any clarification would be appreciated.

2. was addressed in 6.18 by deferring the throttling to the place where
a task exits to user mode. See [1] for further reference.

[1] was not backported to older (stable) kernels but the commit you
referenced at the top was, so the 2. problem is gone there was well.

HTH,
Florian


[1] https://lore.kernel.org/all/20250829081120.806-1-ziqianlu@bytedance.com/