linux-kernel - Re: [tip:core/locking] mutex: Fix optimistic spinning vs. BKL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100519054636.GC12389@ozlabs.org>
Date:	Wed, 19 May 2010 15:46:36 +1000
From:	Tony Breeds <tony@...eyournoodle.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
	a.p.zijlstra@...llo.nl, benh@...nel.crashing.org,
	stable@...nel.org, tglx@...utronix.de,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:core/locking] mutex: Fix optimistic spinning vs. BKL

On Tue, May 18, 2010 at 06:08:38PM +0200, Ingo Molnar wrote:
> 
> * tip-bot for Tony Breeds <tony@...eyournoodle.com> wrote:
> 
> > Commit-ID:  227945799cc10d77c6ef812f3eb8a61a78689454
> > Gitweb:     http://git.kernel.org/tip/227945799cc10d77c6ef812f3eb8a61a78689454
> > Author:     Tony Breeds <tony@...eyournoodle.com>
> > AuthorDate: Fri, 7 May 2010 14:20:10 +1000
> > Committer:  Ingo Molnar <mingo@...e.hu>
> > CommitDate: Tue, 11 May 2010 17:07:24 +0200
> > 
> > mutex: Fix optimistic spinning vs. BKL
> 
> Tony, mind sending a version of this patch that does not 
> include a jiffies based spinning loop?

Subject: [PATCH] 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 both in a rather crude way. I completely disable
spinning if we own the BKL, and I add a safety timeout using jiffies
to fallback to sleeping if we end up spinning for more than 1 or 2
jiffies.

Signed-off-by: Tony Breeds <tony@...eyournoodle.com>
Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: <stable@...nel.org>
---
 kernel/mutex.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/kernel/mutex.c b/kernel/mutex.c
index 632f04c..c38d302 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 (current->lock_depth >= 0)
+			break;
+
+		/*
 		 * If there's an owner, wait for it to either
 		 * release the lock or go to sleep.
 		 */
-- 
1.6.6.1


Yours Tony
--
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/