All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: "Alejandro Colomar" <alx@kernel.org>,
	"Jₑₙₛ Gustedt" <jens.gustedt@inria.fr>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>,
	linux-man@vger.kernel.org, Ulrich Drepper <drepper@redhat.com>,
	Ingo Molnar <mingo@kernel.org>, Todd Lewis <todd.lewis@gs.com>,
	Alexandre Oliva <aoliva@redhat.com>
Subject: Re: bug in futex.2, FUTEX_CMP_REQUEUE
Date: Tue, 27 May 2025 08:12:41 -0400	[thread overview]
Message-ID: <7d4c29a5-6836-48bd-a6c8-009264be000c@redhat.com> (raw)
In-Reply-To: <s5ec3atfffzxdetxbkjgkdiarnuk2yucnpi5j3h3ppqr72mxna@ml6zpucwnbz6>

On 5/27/25 8:01 AM, Alejandro Colomar wrote:
> [Added a few people to CC]
> 
> Hi Jens,
> 
> On Tue, May 27, 2025 at 11:53:03AM +0200, Jₑₙₛ Gustedt wrote:
>> Hello Alex and everybody,
>> I stumbled upon this confusing text in the futex man page
>>
>>    Typical values to specify for `val` are `0` or `1`.  (Specifying
>>    `INT_MAX` is not useful, because it would make the
>>    `FUTEX_CMP_REQUEUE` operation equivalent to `FUTEX_WAKE`.)  The
>>    limit value specified via `val2` is typically either `1` or
>>    `INT_MAX`.  (Specifying the argument as `0` is not useful, because
>>    it would make the `FUTEX_CMP_REQUEUE` operation equivalent to
>>    `FUTEX_WAIT`.)
>>
>>    The `FUTEX_CMP_REQUEUE` operation was added as a replacement for the
>>    earlier `FUTEX_REQUEUE`.  The difference is that the check of the
>>    value at `uaddr` can be used to ensure that requeueing happens only
>>    under certain conditions, which allows race conditions to be avoided
>>    in certain use cases.
>>
>>
>> This has several issues, the most severe beeing the word `FUTEX_WAIT`.
>>
>> - How can an operation that only does wakes, ever be equivalent to a
>>    wait?
> 
> That seems to be a typo.  It seems to me that it would be equivalent to
> FUTEX_WAKE (just like a few sentences before).

As noted in my earlier response, this is not a typo?

> <https://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git/commit/?h=contrib&id=74aa7971e5148f67d5def9977ed87cced638016a>
> 
> 	commit 74aa7971e5148f67d5def9977ed87cced638016a
> 	Author: Alejandro Colomar <alx@kernel.org>
> 	Date:   Tue May 27 13:07:19 2025 +0200
> 
> 	    man/man2/futex.2: tfix
> 	
> 	    Fixes: 3dfcc11d4630 (2015-12-15; "futex.2: Expand description of FUTEX_CMP_REQUEUE")
> 	    Fixes: 8297383e9eeb (2015-12-15; "futex.2: Clean-ups and FIXME removeal after feedback from Thomas Gleixner")
> 	    Reported-by: Jens Gustedt <jens.gustedt@inria.fr>
> 	    Signed-off-by: Alejandro Colomar <alx@kernel.org>
> 
> 	diff --git a/man/man2/futex.2 b/man/man2/futex.2
> 	index 128612ee1..9a15a0fdb 100644
> 	--- a/man/man2/futex.2
> 	+++ b/man/man2/futex.2
> 	@@ -501,7 +501,7 @@ .SS Futex operations
> 	 (Specifying the argument as 0 is not useful, because it would make the
> 	 .B FUTEX_CMP_REQUEUE
> 	 operation equivalent to
> 	-.BR FUTEX_WAIT .)
> 	+.BR FUTEX_WAKE .)

This is incorrect.

A value of zero means no tasks are woken.

The key question here is how do you define or document the semantics
of the linked WAKE/WAIT that puts the tasks in the new queue.

-- 
Cheers,
Carlos.


  reply	other threads:[~2025-05-27 12:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-27  9:53 bug in futex.2, FUTEX_CMP_REQUEUE Jₑₙₛ Gustedt
2025-05-27 11:30 ` Carlos O'Donell
2025-05-27 12:21   ` Jₑₙₛ Gustedt
2025-05-27 12:28     ` Carlos O'Donell
2025-05-27 12:23   ` Alejandro Colomar
2025-05-27 12:35     ` Carlos O'Donell
2025-05-27 12:01 ` Alejandro Colomar
2025-05-27 12:12   ` Carlos O'Donell [this message]
2025-05-27 12:28     ` Jₑₙₛ Gustedt
2025-05-27 12:37       ` Carlos O'Donell
2025-05-27 12:51         ` Alejandro Colomar
2025-05-27 12:54           ` Carlos O'Donell
2025-05-27 12:28     ` Alejandro Colomar
2025-05-27 12:42       ` Carlos O'Donell
2025-05-27 12:57         ` Alejandro Colomar
2025-05-27 12:59           ` Alejandro Colomar
2025-05-27 13:07         ` Jₑₙₛ Gustedt
2025-05-29 23:35   ` Alejandro Colomar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7d4c29a5-6836-48bd-a6c8-009264be000c@redhat.com \
    --to=carlos@redhat.com \
    --cc=alx@kernel.org \
    --cc=aoliva@redhat.com \
    --cc=drepper@redhat.com \
    --cc=jens.gustedt@inria.fr \
    --cc=linux-man@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=todd.lewis@gs.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.