futex: Update futex_wait_setup comments about locking

Reviving a cleanup I had done about a year ago as part of a larger
futex_set_wait proposal. Over the years, the locking of the hashed
futex queue got improved, so that some of the "rare but normal" race
conditions described in comments can't actually happen anymore.

Signed-off-by: Michel Lespinasse <walken@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Darren Hart <dvhltc@us.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
LKML-Reference: <20110307020750.GA31188@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This commit is contained in:
Michel Lespinasse 2011-03-06 18:07:50 -08:00 committed by Thomas Gleixner
parent a5abba989d
commit 8fe8f545c6

View File

@ -1781,13 +1781,14 @@ static int futex_wait_setup(u32 __user *uaddr, u32 val, unsigned int flags,
* *
* The basic logical guarantee of a futex is that it blocks ONLY * The basic logical guarantee of a futex is that it blocks ONLY
* if cond(var) is known to be true at the time of blocking, for * if cond(var) is known to be true at the time of blocking, for
* any cond. If we queued after testing *uaddr, that would open * any cond. If we locked the hash-bucket after testing *uaddr, that
* a race condition where we could block indefinitely with * would open a race condition where we could block indefinitely with
* cond(var) false, which would violate the guarantee. * cond(var) false, which would violate the guarantee.
* *
* A consequence is that futex_wait() can return zero and absorb * On the other hand, we insert q and release the hash-bucket only
* a wakeup when *uaddr != val on entry to the syscall. This is * after testing *uaddr. This guarantees that futex_wait() will NOT
* rare, but normal. * absorb a wakeup if *uaddr does not match the desired values
* while the syscall executes.
*/ */
retry: retry:
ret = get_futex_key(uaddr, flags & FLAGS_SHARED, &q->key); ret = get_futex_key(uaddr, flags & FLAGS_SHARED, &q->key);