[Bug nptl/29371] New: pthread rwlocks are not priority inheritance aware

[Bug nptl/29371] New: pthread rwlocks are not priority inheritance aware

[brenda.streiff at ni dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29371

            Bug ID: 29371
           Summary: pthread rwlocks are not priority inheritance aware
           Product: glibc
           Version: 2.25
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: brenda.streiff at ni dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

Created attachment 14212
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14212&action=edit
test application for exercising pthread_rwlock_wrlock from mixed priorities

glibc pthread rwlocks are susceptible to priority inversion deadlocks.

With the attached testcase we're able to observe a situation where a
low-priority thread has a lock acquired while a high-priority SCHED_FIFO thread
is looping in __pthread_rwlock_wrlock_full64; under a PREEMPT_RT Linux kernel
with RT throttling disabled, if there are are more higher-priority threads than
there are CPUs-- all CPUs end up spinning waiting for a lower-priority thread
(which can never get time to run) to release the wrlock, and the system will
lock.

In glibc 2.24, the nptl rwlock implementation was built solely out of futex
syscalls, which enter into the kernel and provide a preemption point; thus
priority-inverted cases would still block high-priority threads and allow
low-priority lock holders to make progress.

In glibc 2.25 (and the current implementation), the rwlocks were reimplemented
in cc25c8b4c119 ("New pthread rwlock that is more scalable.") with an
implementation that uses futexes along with spinning over atomic operations;
that spinning can become non-preemptable on PREEMPT_RT.

2.9.6 Thread Read-Write Locks [1] in the System Interfaces section of IEEE Std
1003.1-2017 says that:

> A thread that has blocked on a read-write lock (for example, has not yet
> returned from a pthread_rwlock_rdlock() or pthread_rwlock_wrlock() call)
> shall not prevent any unblocked thread that is eligible to use the same
> processing resources from eventually making forward progress in its
> execution. Eligibility for processing resources shall be determined by
> the scheduling policy.

However, it would appear to be the case that in the current implementation in
real-time use cases that high-priority threads in pthread_rwlock_wrlock() _can_
prevent an unblocked thread (the wrlock holder) from making forward progress.

We're looking for some guidance on whether real-time use cases should be
supported in this manner. pthread condvars have similar priority issues with no
way to have them opt-in to PTHREAD_PRIO_INHERIT (bug #11588)-- is this a glibc
deficiency or it is a gap in POSIX? If it is a glibc deficiency, how should we
address it?

[1]
https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_06

-- 
You are receiving this mail because:
You are on the CC list for the bug.