From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 44D173857BBF; Fri, 15 Jul 2022 18:35:33 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 44D173857BBF From: "brenda.streiff at ni dot com" To: glibc-bugs@sourceware.org Subject: [Bug nptl/29371] New: pthread rwlocks are not priority inheritance aware Date: Fri, 15 Jul 2022 18:35:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: 2.25 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: brenda.streiff at ni dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2022 18:35:33 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29371 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=3D14212&action=3Ded= it 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 th= read is looping in __pthread_rwlock_wrlock_full64; under a PREEMPT_RT Linux kern= el 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 thre= ad (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 reimplemen= ted 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 progres= s. We're looking for some guidance on whether real-time use cases should be supported in this manner. pthread condvars have similar priority issues wit= h no way to have them opt-in to PTHREAD_PRIO_INHERIT (bug #11588)-- is this a gl= ibc 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#t= ag_15_09_06 --=20 You are receiving this mail because: You are on the CC list for the bug.=