From: tip-bot for Darren Hart <dvhltc@us.ibm.com>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, dvhltc@us.ibm.com, hpa@zytor.com,
mingo@redhat.com, eric.dumazet@gmail.com, johnstul@us.ibm.com,
peterz@infradead.org, dino@in.ibm.com, rostedt@goodmis.org,
tglx@linutronix.de, mingo@elte.hu
Subject: [tip:core/urgent] futex: Fix wakeup race by setting TASK_INTERRUPTIBLE before queue_me()
Date: Tue, 22 Sep 2009 08:41:29 GMT [thread overview]
Message-ID: <tip-0729e196147692d84d4c099fcff056eba2ed61d8@git.kernel.org> (raw)
In-Reply-To: <20090922053038.8717.97838.stgit@Aeon>
Commit-ID: 0729e196147692d84d4c099fcff056eba2ed61d8
Gitweb: http://git.kernel.org/tip/0729e196147692d84d4c099fcff056eba2ed61d8
Author: Darren Hart <dvhltc@us.ibm.com>
AuthorDate: Mon, 21 Sep 2009 22:30:38 -0700
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Tue, 22 Sep 2009 10:37:44 +0200
futex: Fix wakeup race by setting TASK_INTERRUPTIBLE before queue_me()
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>
---
kernel/futex.c | 15 +++------------
1 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index f92afbe..463af2e 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1656,17 +1656,8 @@ out:
static void futex_wait_queue_me(struct futex_hash_bucket *hb, struct futex_q *q,
struct hrtimer_sleeper *timeout)
{
- queue_me(q, hb);
-
- /*
- * There might have been scheduling since the queue_me(), as we
- * cannot hold a spinlock across the get_user() in case it
- * faults, and we cannot just set TASK_INTERRUPTIBLE state when
- * queueing ourselves into the futex hash. This code thus has to
- * rely on the futex_wake() code removing us from hash when it
- * wakes us up.
- */
set_current_state(TASK_INTERRUPTIBLE);
+ queue_me(q, hb);
/* Arm the timer */
if (timeout) {
@@ -1676,8 +1667,8 @@ static void futex_wait_queue_me(struct futex_hash_bucket *hb, struct futex_q *q,
}
/*
- * !plist_node_empty() is safe here without any lock.
- * q.lock_ptr != 0 is not safe, because of ordering against wakeup.
+ * If we have been removed from the hash list, then another task
+ * has tried to wake us, and we can skip the call to schedule().
*/
if (likely(!plist_node_empty(&q->list))) {
/*
prev parent reply other threads:[~2009-09-22 8:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-22 5:29 [PATCH 0/5] Futex cleanups and race fix Darren Hart
2009-09-22 5:29 ` [PATCH 1/5] futex: correct futex_wait_requeue_pi() commentary Darren Hart
2009-09-22 8:40 ` [tip:core/urgent] futex: Correct " tip-bot for Darren Hart
2009-09-22 5:30 ` [PATCH 2/5] futex: correct queue_me and unqueue_me commentary Darren Hart
2009-09-22 8:40 ` [tip:core/urgent] futex: Correct " tip-bot for Darren Hart
2009-09-22 5:30 ` [PATCH 3/5] futex: make function kernel-doc commentary consistent Darren Hart
2009-09-22 8:41 ` [tip:core/urgent] futex: Make " tip-bot for Darren Hart
2009-09-22 5:30 ` [PATCH 4/5] futex: correct futex_q woken state commentary Darren Hart
2009-09-22 8:41 ` [tip:core/urgent] futex: Correct " tip-bot for Darren Hart
2009-09-22 5:30 ` [PATCH 5/5] futex: fix wakeup race by setting TASK_INTERRUPTIBLE before queue_me Darren Hart
2009-09-22 8:38 ` Eric Dumazet
2009-09-22 9:10 ` Ingo Molnar
2009-09-22 17:21 ` Darren Hart
2009-09-22 19:26 ` Ingo Molnar
2009-09-22 8:41 ` tip-bot for Darren Hart [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tip-0729e196147692d84d4c099fcff056eba2ed61d8@git.kernel.org \
--to=dvhltc@us.ibm.com \
--cc=dino@in.ibm.com \
--cc=eric.dumazet@gmail.com \
--cc=hpa@zytor.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox