From: tip-bot for Tony Breeds <tony@bakeyournoodle.com>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@redhat.com,
a.p.zijlstra@chello.nl, torvalds@linux-foundation.org,
benh@kernel.crashing.org, stable@kernel.org, tglx@linutronix.de,
mingo@elte.hu, tony@bakeyournoodle.com
Subject: [tip:core/urgent] mutex: Fix optimistic spinning vs. BKL
Date: Wed, 19 May 2010 07:56:43 GMT [thread overview]
Message-ID: <tip-fd6be105b883244127a734ac9f14ae94a022dcc0@git.kernel.org> (raw)
In-Reply-To: <20100519054636.GC12389@ozlabs.org>
Commit-ID: fd6be105b883244127a734ac9f14ae94a022dcc0
Gitweb: http://git.kernel.org/tip/fd6be105b883244127a734ac9f14ae94a022dcc0
Author: Tony Breeds <tony@bakeyournoodle.com>
AuthorDate: Wed, 19 May 2010 15:46:36 +1000
Committer: Ingo Molnar <mingo@elte.hu>
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@bakeyournoodle.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: <stable@kernel.org>
LKML-Reference: <20100519054636.GC12389@ozlabs.org>
[ added an unlikely() attribute to the branch ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
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.
*/
prev parent reply other threads:[~2010-05-19 7:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-28 4:38 [PATCH/RFC] mutex: Fix optimistic spinning vs. BKL Benjamin Herrenschmidt
2010-04-28 4:39 ` Benjamin Herrenschmidt
2010-04-28 12:06 ` Arnd Bergmann
2010-04-28 22:35 ` Benjamin Herrenschmidt
2010-05-07 4:20 ` Tony Breeds
2010-05-07 5:30 ` Frederic Weisbecker
2010-05-07 6:01 ` Benjamin Herrenschmidt
2010-05-07 21:29 ` Frederic Weisbecker
2010-05-07 22:27 ` Benjamin Herrenschmidt
2010-05-10 7:55 ` Peter Zijlstra
2010-05-11 18:06 ` Linus Torvalds
2010-05-11 18:19 ` Peter Zijlstra
2010-05-11 21:13 ` Benjamin Herrenschmidt
2010-05-07 6:16 ` Mike Galbraith
2010-05-11 15:43 ` [tip:core/locking] " tip-bot for Tony Breeds
2010-05-11 23:05 ` Tony Breeds
2010-05-18 16:08 ` Ingo Molnar
2010-05-18 16:26 ` Linus Torvalds
2010-05-19 5:46 ` Tony Breeds
2010-05-19 7:56 ` tip-bot for Tony Breeds [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-fd6be105b883244127a734ac9f14ae94a022dcc0@git.kernel.org \
--to=tony@bakeyournoodle.com \
--cc=a.p.zijlstra@chello.nl \
--cc=benh@kernel.crashing.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=stable@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.