linux-kernel - [PATCH v2 5/5] man/man3/pthread_cond_init.3: Add a note regarding real-time usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250915141305.906440-6-bigeasy@linutronix.de>
Date: Mon, 15 Sep 2025 16:13:05 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: linux-kernel@...r.kernel.org,
	linux-man@...r.kernel.org
Cc: Alejandro Colomar <alx@...nel.org>,
	André Almeida <andrealmeid@...lia.com>,
	Darren Hart <dvhart@...radead.org>,
	Davidlohr Bueso <dave@...olabs.net>,
	Ingo Molnar <mingo@...hat.com>,
	Juri Lelli <juri.lelli@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Valentin Schneider <vschneid@...hat.com>,
	Waiman Long <longman@...hat.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: [PATCH v2 5/5] man/man3/pthread_cond_init.3: Add a note regarding real-time usage

The "old" implementation led to priority inversion and was more or less
easy to trigger. It seems that after the rewrite the issue disappeared
especially since the old workaround does not apply anymore.

Add a note mentioning the old problem and why the issue is not gone
since the rewrite in glibc 2.25 but harder to trigger.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
---
 man/man3/pthread_cond_init.3 | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/man/man3/pthread_cond_init.3 b/man/man3/pthread_cond_init.3
index 0045e7ecee075..779f6de6d064b 100644
--- a/man/man3/pthread_cond_init.3
+++ b/man/man3/pthread_cond_init.3
@@ -115,6 +115,7 @@ if all threads always acquire the mutex before signaling the condition,
 this guarantees that the condition cannot be signaled (and thus ignored)
 between the time a thread locks the mutex
 and the time it waits on the condition variable.
+See NOTES below.
 .P
 .BR pthread_cond_timedwait ()
 atomically unlocks
@@ -240,6 +241,26 @@ Some threads are currently waiting on
 .BR gettimeofday (2),
 .BR nanosleep (2).
 .
+.SH NOTES
+The implementation of the provided functions until
+glibc 2.25 used an internal data lock.
+This lock did not support priority-inheritance and
+was subject to unbounded priority inversion,
+visible on a real-time system.
+After the rewrite of the implementation in 2.25
+the usage of internal lock changed.
+The internal lock is always acquired by
+the signaling functions
+.BR pthread_cond_signal ()
+and
+.BR pthread_cond_broadcast ().
+The waiting function acquires the lock
+if the waiting process was interrupted.
+The interruption can be caused for instance by a specified timeout
+and denoted by the error value
+.B ETIMEDOUT
+or a received signal which is denoted by the error value
+.BR EINTR .
 .
 .SH EXAMPLE
 Consider two shared variables
-- 
2.51.0