diff options
| -rw-r--r-- | man2/futex.2 | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/man2/futex.2 b/man2/futex.2 index 630448e2e0..8185a3126d 100644 --- a/man2/futex.2 +++ b/man2/futex.2 @@ -434,6 +434,11 @@ This load, the comparison with .IR val3 , and the requeueing of any waiters are performed atomically and totally ordered with respect to other operations on the same futex word. +.\" Notes from a f2f conversation with Thomas Gleixner (Aug 2015): ### +.\" The operation is serialized with respect to operations on both +.\" source and target futex. No other waiter can enqueue itself +.\" for waiting and no other waiter can dequeue itself because of +.\" a timeout or signal. Typical values to specify for .I val @@ -1055,6 +1060,16 @@ This can happen when the owner of the futex died. .\" User space cannot handle this condition in a race-free manner, but the kernel can fix this up and acquire the futex. +.\" Paraphrasing a f2f conversation with Thomas Gleixner about the +.\" above point (Aug 2015): ### +.\" There is a rare possibility of a race condition involving an +.\" uncontended futex with no owner, but with waiters. The +.\" kernel-user-space contract is that if a futex is nonzero, you must +.\" go into kernel. The futex was owned by a task, and that task dies +.\" but there are no waiters, so the futex value is non zero. +.\" Therefore, the next locker has to go into the kernel, +.\" so that the kernel has a chance to clean up. (CMXCH on zero +.\" in user space would fail, so kernel has to clean up.) The .IR uaddr2 , @@ -1465,6 +1480,9 @@ or The kernel detected an inconsistency between the user-space state at .I uaddr2 and the kernel state; +.\" From a conversation with Thomas Gleixner (Aug 2015): ### +.\" The kernel sees: I have non PI state for a futex you tried to +.\" tell me was PI that is, the kernel detected a waiter which waits via .BR FUTEX_WAIT or |