futex: Fix wakeup race by setting TASK_INTERRUPTIBLE before queue_me()
commiteb20f6f5ae9b4198039f30d9177baf226488c15c
authorDarren Hart <dvhltc@us.ibm.com>
Tue, 22 Sep 2009 05:30:38 +0000 (21 22:30 -0700)
committerGreg Kroah-Hartman <gregkh@suse.de>
Thu, 22 Oct 2009 22:11:52 +0000 (22 15:11 -0700)
tree502fad2e39bd7d762bd653130daf0ad8d3217d69
parente43391f135ddf1cefc305bed9ce18d34b07bdcdd
futex: Fix wakeup race by setting TASK_INTERRUPTIBLE before queue_me()

commit 0729e196147692d84d4c099fcff056eba2ed61d8 upstream.

PI futexes do not use the same plist_node_empty() test for wakeup.
It was possible for the waiter (in futex_wait_requeue_pi()) to set
TASK_INTERRUPTIBLE after the waker assigned the rtmutex to the
waiter. The waiter would then note the plist was not empty and call
schedule(). The task would not be found by any subsequeuent futex
wakeups, resulting in a userspace hang.

By moving the setting of TASK_INTERRUPTIBLE to before the call to
queue_me(), the race with the waker is eliminated. Since we no
longer call get_user() from within queue_me(), there is no need to
delay the setting of TASK_INTERRUPTIBLE until after the call to
queue_me().

The FUTEX_LOCK_PI operation is not affected as futex_lock_pi()
relies entirely on the rtmutex code to handle schedule() and
wakeup.  The requeue PI code is affected because the waiter starts
as a non-PI waiter and is woken on a PI futex.

Remove the crusty old comment about holding spinlocks() across
get_user() as we no longer do that. Correct the locking statement
with a description of why the test is performed.

Signed-off-by: Darren Hart <dvhltc@us.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Dinakar Guniguntala <dino@in.ibm.com>
Cc: John Stultz <johnstul@us.ibm.com>
LKML-Reference: <20090922053038.8717.97838.stgit@Aeon>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
kernel/futex.c