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

[K Prateek Nayak]

Hello Ran,

On 9/4/2026 1:41 PM, 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.

This has been solved by putting off CFS bandwidth throttling until the
task exits to the userspace in
https://lore.kernel.org/lkml/20250829081120.806-1-ziqianlu@xxxxxxxxxxxxx/
which landed in v6.18.

> Are these issues PREEMPT_RT-specific?

If you are running older version, stalls may be specific to PREEMPT_RT
since {read,write}_lock_irq* variants don't disable IRQs on PREEMPT_RT
and can tasks can get preempted (and throttled) in a rw_lock critical
section.

In addition to this, on PREEMPT_RT, a pending writer will make the future
readers wait until the writer is finished but there are optimizations on
!PREEMPT_RT that allows readers to jump ahead of a writer if concurrent
readers are present.

If a task takes a rw_lock and is trotthed in critical section and the
other end of that lock is later required by ktimers/n, the bandwidth
timer, which is also queued on ktimers/n will never run and allow for
unthrottling. Without untrottle, the first task never releases the lock.

Couple of reports from past are:

1. https://lore.kernel.org/linux-rt-users/xhsmhttqvnall.mognet@xxxxxxxxxxxxxxxxxxx/
2. https://lore.kernel.org/all/7483d3ae-5846-4067-b9f7-390a614ba408@xxxxxxxxxxx/

There is a small breakdown of how 2. can lead to a stall here:

https://lore.kernel.org/all/e65a32af-271b-4de6-937a-1a1049bbf511@xxxxxxx/

> Any clarification would be appreciated.

If you are running kernel version v6.18 or newer, the stalls from
bandwidth throttling shouldn't be an issue.

Priority inversion with rw_lock is still possible until we get
SCHED_PROXY_EXEC support and integrate it with PREEMPT_RT bits.

-- 
Thanks and Regards,
Prateek