[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tip-7539a3b3d1f892dd97eaf094134d7de55c13befe@git.kernel.org>
Date: Sun, 13 Dec 2009 07:36:42 GMT
From: "tip-bot for Rafael J. Wysocki" <rjw@...k.pl>
To: linux-tip-commits@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
hpa@...or.com, mingo@...hat.com, stern@...land.harvard.edu,
a.p.zijlstra@...llo.nl, torvalds@...ux-foundation.org,
rui.zhang@...el.com, lachlan@....com, david@...morbit.com,
tglx@...utronix.de, rjw@...k.pl, mingo@...e.hu
Subject: [tip:sched/urgent] sched: Make wakeup side and atomic variants of completion API irq safe
Commit-ID: 7539a3b3d1f892dd97eaf094134d7de55c13befe
Gitweb: http://git.kernel.org/tip/7539a3b3d1f892dd97eaf094134d7de55c13befe
Author: Rafael J. Wysocki <rjw@...k.pl>
AuthorDate: Sun, 13 Dec 2009 00:07:30 +0100
Committer: Ingo Molnar <mingo@...e.hu>
CommitDate: Sun, 13 Dec 2009 08:12:46 +0100
sched: Make wakeup side and atomic variants of completion API irq safe
Alan Stern noticed that all the wakeup side (and atomic) variants of the
completion APIs should be irq safe, but the newly introduced
completion_done() and try_wait_for_completion() aren't. The use of the
irq unsafe variants in IRQ contexts can cause crashes/hangs.
Fix the problem by making them use spin_lock_irqsave() and
spin_lock_irqrestore().
Reported-by: Alan Stern <stern@...land.harvard.edu>
Signed-off-by: Rafael J. Wysocki <rjw@...k.pl>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Zhang Rui <rui.zhang@...el.com>
Cc: pm list <linux-pm@...ts.linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: David Chinner <david@...morbit.com>
Cc: Lachlan McIlroy <lachlan@....com>
LKML-Reference: <200912130007.30541.rjw@...k.pl>
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
kernel/sched.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index ff39cad..8b3532f 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -5908,14 +5908,15 @@ EXPORT_SYMBOL(wait_for_completion_killable);
*/
bool try_wait_for_completion(struct completion *x)
{
+ unsigned long flags;
int ret = 1;
- spin_lock_irq(&x->wait.lock);
+ spin_lock_irqsave(&x->wait.lock, flags);
if (!x->done)
ret = 0;
else
x->done--;
- spin_unlock_irq(&x->wait.lock);
+ spin_unlock_irqrestore(&x->wait.lock, flags);
return ret;
}
EXPORT_SYMBOL(try_wait_for_completion);
@@ -5930,12 +5931,13 @@ EXPORT_SYMBOL(try_wait_for_completion);
*/
bool completion_done(struct completion *x)
{
+ unsigned long flags;
int ret = 1;
- spin_lock_irq(&x->wait.lock);
+ spin_lock_irqsave(&x->wait.lock, flags);
if (!x->done)
ret = 0;
- spin_unlock_irq(&x->wait.lock);
+ spin_unlock_irqrestore(&x->wait.lock, flags);
return ret;
}
EXPORT_SYMBOL(completion_done);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists