Darren Hart pointed me to the comments from Rich Felker
that there are valid use cases for FUTEX_REQUEUE.
From: Rich Felker <dalias@libc.org>
Date: Wed, 29 Oct 2014 22:43:17 -0400
To: Darren Hart <dvhart@infradead.org>
Cc: GLIBC Devel <libc-alpha@sourceware.org>, ...
Subject: Re: Add futex wrapper to glibc?
On Wed, Oct 29, 2014 at 06:59:15PM -0700, Darren Hart wrote:
[...]
> I wonder though... can we not wrap FUTEX_REQUEUE? It's fundamentally
> broken. FUTEX_CMP_REQUEUE should *always* be used instead. The glibc
> wrapper is one way to encourage developers to do the right thing
> (don't expose the bad op in the header).
You're mistaken here. There are plenty of valid ways to use
FUTEX_REQUEUE - for example if the calling thread is requeuing the
target(s) to a lock that the calling thread owns. Just because it
doesn't meet the needs of the way glibc was using it internally
doesn't mean it's useless for other applications.
Reported-by: Darren Hart <dvhart@infradead.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As commented on by Davidlohr Bueso:
This to me reads a bit too much into the kernel (fastpath,
refcnt, vmas). Why not just mention that it avoids overhead
in the kernel or something? I don't recall any manpage
mentioning such details, but I could be wrong.
Reported-by: Davidlohr Bueso <dave@stgolabs.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The kernel uses the following cast:
if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE ||
cmd == FUTEX_CMP_REQUEUE_PI || cmd == FUTEX_WAKE_OP)
val2 = (u32) (unsigned long) utime;
This ensures that always the least significant four bytes of the
pointer are used, both on ILP32 and LP64 systems.
On a big endian system a simple cast from 64 bit pointer to 32 bit
integer would return the most significant four bytes.
We have to make the reader of the man-page aware of the usage
of the least significant bytes.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Type u32 is not exposed to the user. Instead, refer to uint32_t,
which is defined in ISO/IEC 9899:1999.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Using the word "physical" address should make the text easier to
make.
Avoid negations like "may not be equal".
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Here is the result of a first pass over futex.2. I tried to
do nothing that is too controversial. I tried to apply the
terminology that at least Darren and I had in mind
consistently; but please check again.
The major changes are in how futexes are described in the
introductory parts of the page. I hope it's easier to understand
now. I've also tried to add some more precision to the the
description of the synchronization semantics (e.g., it makes a
difference whether we claim something is atomic (without further
qualification), or just atomic wrt. other futex operations).
In some cases, that adds some verbosity to the text -- but I
believe that this is worth the clarity and consistency in using
terms, for example.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As reported by Rich Felker:
I see no code in the kernel whereby a "spurious wakeup",
or anything other than interruption by a signal handler
that's not SA_RESTART, can cause futex to fail with EINTR.
In general, overloading of EINTR and/or spurious EINTRs
from a syscall make it impossible to use that syscall for
implementing any function where EINTR is a mandatory
failure on interruption-by-signal, since there is no way
for userspace to distinguish whether the EINTR occurred
as a result of an interrupting signal or some other
reason. The kernel folks have gone to great lengths to fix
spurious EINTRs (see signal(7) for history), especially by
non-interrupting signal handlers, including in futex, and
allowing EINTR here would be contrary to that goal.
It's my belief that the "or a spurious wakeup" text should
simply be removed.
The reason I'm raising this topic is its relevance to a
thread on libc-alpha:
[RFC] mutex destruction (#13690): problem description and workarounds
The bug and mailing list discussions to which Rich refers are:
https://sourceware.org/bugzilla/show_bug.cgi?id=13690https://sourceware.org/ml/libc-alpha/2014-12/threads.html#0001
Torvald Riegel also reported the same issue, and Thomas Gleixner
noted that the "EINTR on spurious wakeup" behavior went away in
Linux 2.6.22. See the LKML thread, "futex() man page update help
request", Jan 2015:
http://thread.gmane.org/gmane.linux.kernel/1703405/focus=7734
Reported-by: Rich Felker <dalias@libc.org>
Reported-by: Torvald Riegel <triegel@redhat.com>
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Michael Kerrisk <mtknpages@gmail.com>
Michael Kerrisk