[tip:core/urgent] mutex: Fix optimistic spinning vs. BKL

From: tip-bot for Tony Breeds
Date: Wed May 19 2010 - 03:57:25 EST


Commit-ID: fd6be105b883244127a734ac9f14ae94a022dcc0
Gitweb: http://git.kernel.org/tip/fd6be105b883244127a734ac9f14ae94a022dcc0
Author: Tony Breeds <tony@xxxxxxxxxxxxxxxxxx>
AuthorDate: Wed, 19 May 2010 15:46:36 +1000
Committer: Ingo Molnar <mingo@xxxxxxx>
CommitDate: Wed, 19 May 2010 08:18:44 +0200

mutex: Fix optimistic spinning vs. BKL

Currently, we can hit a nasty case with optimistic
spinning on mutexes:

CPU A tries to take a mutex, while holding the BKL

CPU B tried to take the BLK while holding the mutex

This looks like a AB-BA scenario but in practice, is
allowed and happens due to the auto-release on
schedule() nature of the BKL.

In that case, the optimistic spinning code can get us
into a situation where instead of going to sleep, A
will spin waiting for B who is spinning waiting for
A, and the only way out of that loop is the
need_resched() test in mutex_spin_on_owner().

This patch fixes it by completely disabling spinning
if we own the BKL. This adds one more detail to the
extensive list of reasons why it's a bad idea for
kernel code to be holding the BKL.

Signed-off-by: Tony Breeds <tony@xxxxxxxxxxxxxxxxxx>
Acked-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Acked-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
Cc: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
Cc: <stable@xxxxxxxxxx>
LKML-Reference: <20100519054636.GC12389@xxxxxxxxxx>
[ added an unlikely() attribute to the branch ]
Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
---
kernel/mutex.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/kernel/mutex.c b/kernel/mutex.c
index 632f04c..4c0b7b3 100644
--- a/kernel/mutex.c
+++ b/kernel/mutex.c
@@ -172,6 +172,13 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
struct thread_info *owner;

/*
+ * If we own the BKL, then don't spin. The owner of
+ * the mutex might be waiting on us to release the BKL.
+ */
+ if (unlikely(current->lock_depth >= 0))
+ break;
+
+ /*
* If there's an owner, wait for it to either
* release the lock or go to sleep.
*/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/