[lkml]   [2010]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[patch 014/149] mutex: Fix optimistic spinning vs. BKL
2.6.32-stable review patch.  If anyone has any objections, please let us know.


From: Tony Breeds <>

commit fd6be105b883244127a734ac9f14ae94a022dcc0 upstream.

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 <>
Acked-by: Linus Torvalds <>
Acked-by: Peter Zijlstra <>
Cc: Benjamin Herrenschmidt <>
LKML-Reference: <>
[ added an unlikely() attribute to the branch ]
Signed-off-by: Ingo Molnar <>
Signed-off-by: Greg Kroah-Hartman <>

kernel/mutex.c | 7 +++++++
1 file changed, 7 insertions(+)

--- a/kernel/mutex.c
+++ b/kernel/mutex.c
@@ -172,6 +172,13 @@ __mutex_lock_common(struct mutex *lock,
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.

 \ /
  Last update: 2010-07-01 20:55    [W:1.108 / U:29.876 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site