LDP
/
man-pages
mirror of https://github.com/mkerrisk/man-pages
0
1
Fork 0
Code Releases Activity

futex Since Linux 2.6.22, EINTR can no longer occur on spurious wakeup 

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=13690
     https://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>
This commit is contained in:
Michael Kerrisk 2015-01-27 07:02:07 +01:00
parent 9732dd8b3f
commit f529fd2013
1 changed files with 3 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
man2/futex.2
View File

@ -1183,37 +1183,10 @@ A
or
.B FUTEX_WAIT_BITSET
operation was interrupted by a signal (see
.BR signal (7))
.BR signal (7)).
In kernels before Linux 2.6.22, this error could also be returned for
on a spurious wakeup; since Linux 2.6.22, this no longer happens.
or a spurious wakeup.
.\" FIXME
.\" Regarding the words "spurious wakeup" above, I received this
.\" bug report from 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=13690
.\" https://sourceware.org/ml/libc-alpha/2014-12/threads.html#0001
.\"
.\" Can anyone comment on whether the words "spurious wakeup" are correct?
.\"
.TP
.B EINVAL
The operation in