mirror of https://github.com/mkerrisk/man-pages
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:
parent
9732dd8b3f
commit
f529fd2013
33
man2/futex.2
33
man2/futex.2
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue