linux-kernel - Re: [PATCH 3/4] man/man2/futex.2: Recycle two gmane URLs

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: <710e8f05-b0b3-489a-9e89-8967cf6a9e70@redhat.com>
Date: Fri, 29 Aug 2025 13:54:58 -0400
From: Carlos O'Donell <carlos@...hat.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org, linux-man@...r.kernel.org,
 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>
Subject: Re: [PATCH 3/4] man/man2/futex.2: Recycle two gmane URLs

On 8/29/25 1:39 PM, Sebastian Andrzej Siewior wrote:
> On 2025-08-29 12:43:26 [-0400], Carlos O'Donell wrote:
>>> index 69df4036ada7f..027e91b826bf1 100644
>>> --- a/man/man2/futex.2
>>> +++ b/man/man2/futex.2
>>> @@ -6,10 +6,10 @@
>>>    .\"
>>>    .\" FIXME Still to integrate are some points from Torvald Riegel's mail of
>>>    .\" 2015-01-23:
>>> -.\"       http://thread.gmane.org/gmane.linux.kernel/1703405/focus=7977
>>> +.\"       https://lore.kernel.org/lkml/1422037788.29655.0.camel@triegel.csb
>>
>> Wrong link?
>>
>> Should be this link:
>> https://lore.kernel.org/lkml/1422037145.27573.0.camel@triegel.csb/
>>
>> Where the discussion is about the unresolved constraint to guarantee FIFO order.
> 
> I thought it is the longer email, the second that day, where he made
> three points. Didn't read it (yet)…

Given the dates and the disjoint set of topics, my suggestion is the link above.

> Now FIFO ordering you say. Is it glibc's side or kernel side? The kernel
> sorts the futex waiters according their (task's) priority. It is not
> FIFO unless the tasks are of equal priority.

The FIFO order question was a kernel-side question wrt futex semantics.
At least that's how I read the thread. And the issue was resolved, but possibly
not documented. Documentation might include stating "FIFO ordering over all
waiters, or even a subset of waiters (at the same priority level) is not
guaranteed."

Torvald was right that for POSIX condition variables we would naturally want
a FIFO wake order so earlier sleepers are woken first.

> So a futex requeue will take the task with the highest priority from
> uaddr1 and move it to uaddr2.

Right.

-- 
Cheers,
Carlos.