linux-kernel - Re: [PATCH] Documentation: locking: update libc support status of PI futexes

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250523150028.62N5N42-@linutronix.de>
Date: Fri, 23 May 2025 17:00:28 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Alison Chaiken <alison@...-devel.com>
Cc: corbet@....net, gratian.crisan@...com, triegel@...hat.com,
	rostedt@...dmis.org, linux-kernel@...r.kernel.org,
	linux-rt-users@...r.kernel.org, achaiken@...ora.tech
Subject: Re: [PATCH] Documentation: locking: update libc support status of PI
 futexes

On 2025-01-11 10:55:55 [-0800], Alison Chaiken wrote:
> > Are you sure? My memory is that glibc avoided using the internal mutex.
> > The old problem should be gone and pthread_cond_signal() and
> > pthread_cond_wait() should work.
> 
> Ignoring support for 64-bit time, the last substantive change to
> pthread_cond_wait() and pthread_cond_signal() was Torvald Riegel's  commit
> ed19993b5b0d05d62cc883571519a67dae481a14 "New condvar implementation that
> provides stronger ordering guarantees," which fixed problems with waking of
> ineligible futex waiters and with ABA issues concerning the futex word.
> What the patch does not do is made clear by the commit message:
> 
>      This condvar doesn't yet use a requeue optimization (ie, on a
> broadcast,
>      waking just one thread and requeueing all others on the futex of the
>      mutex supplied by the program).
> 
> What futex-requeue-pi.rst directs is
> 
>      In order to support PI-aware pthread_condvar's, the kernel needs to
>      be able to requeue tasks to PI futexes.
> 
> Riegel and Darren Hart discussed Riegel's patch in at length at the 2016 RT
> Summit:
> 
> https://wiki.linuxfoundation.org/realtime/events/rt-summit2016/schedule
> 
> The related glibc bug report by Darren may be found at
> 
>     https://sourceware.org/bugzilla/show_bug.cgi?id=11588
> 
> The last comment on the bug from 2017 is by Riegel:
> 
>     So far, there is no known solution for how to achieve PI support given
> the current constraints we have (eg, available futex operations, POSIX
> requirements, ...).
> 
> I ran the bug reproducer posted by Darren in Qemu and found that it did not
> fail.   I'm not sure if the result is valid given the peculiarities of Qemu,
> or whether I made some other mistake.

I've been looking at this again for other reasons and looked at the
code again…

Back then we use futex-requeue API and required both futex-object to
have the PI bit set. This wasn't the case originally, hence the patch by
Darren which did not make it into the official libc.

With the rework by Riegel, the mutex within pthread's condvar
implementation is gone also the usage of the requeue API. The
pthread_cond_wait()/ pthread_cond_signal() API is back to use futex'
wait/ wake.
The glibc comments write something about important ordering constrains.
The futex wait enqueues the waiter according to its priority. So the
task with highest priority gets always a front seat. The futex wake
function wakes always the first waiter in the queue.

With all this I would say that the glib'c condvar implementation does
not have any issues since the rework.
There were a few loops, with a 0 retry counter (basically dead) and they
have been removed.

Sebastian