From: Peter Zijlstra <peterz@infradead.org>
To: Jason Low <jason.low2@hp.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
"Michael L. Semon" <mlsemon35@gmail.com>,
Ingo Molnar <mingo@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: 3.14.0+/x86: lockdep and mutexes not getting along
Date: Thu, 10 Apr 2014 16:15:59 +0200 [thread overview]
Message-ID: <20140410141559.GE13658@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20140410091824.GL10526@twins.programming.kicks-ass.net>
On Thu, Apr 10, 2014 at 11:18:24AM +0200, Peter Zijlstra wrote:
> So I managed to reproduce, and the below makes it go away. I just don't
> understand why though. will stare more.
/me kicks himself.. bloody obvious fail there :-)
Not unlocking the lock after a lockdep trigger will make things get
stuck real fast :-)
---
kernel/locking/mutex-debug.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
index e1191c996c59..5cf6731b98e9 100644
--- a/kernel/locking/mutex-debug.c
+++ b/kernel/locking/mutex-debug.c
@@ -71,18 +71,17 @@ void mutex_remove_waiter(struct mutex *lock, struct mutex_waiter *waiter,
void debug_mutex_unlock(struct mutex *lock)
{
- if (unlikely(!debug_locks))
- return;
+ if (likely(debug_locks)) {
+ DEBUG_LOCKS_WARN_ON(lock->magic != lock);
- DEBUG_LOCKS_WARN_ON(lock->magic != lock);
+ if (!lock->owner)
+ DEBUG_LOCKS_WARN_ON(!lock->owner);
+ else
+ DEBUG_LOCKS_WARN_ON(lock->owner != current);
- if (!lock->owner)
- DEBUG_LOCKS_WARN_ON(!lock->owner);
- else
- DEBUG_LOCKS_WARN_ON(lock->owner != current);
-
- DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next);
- mutex_clear_owner(lock);
+ DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next);
+ mutex_clear_owner(lock);
+ }
/*
* __mutex_slowpath_needs_to_unlock() is explicitly 0 for debug
next prev parent reply other threads:[~2014-04-10 18:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-06 5:12 3.14.0+/x86: lockdep and mutexes not getting along Michael L. Semon
2014-04-09 12:19 ` Kirill A. Shutemov
2014-04-10 5:42 ` Jason Low
2014-04-10 8:14 ` Peter Zijlstra
2014-04-10 9:15 ` Kirill A. Shutemov
2014-04-10 11:42 ` Peter Zijlstra
2014-04-10 9:18 ` Peter Zijlstra
2014-04-10 14:15 ` Peter Zijlstra [this message]
2014-04-11 13:59 ` Valdis.Kletnieks
2014-04-14 7:22 ` [tip:core/urgent] locking/mutex: Fix debug_mutexes tip-bot for Peter Zijlstra
2014-04-10 17:14 ` 3.14.0+/x86: lockdep and mutexes not getting along Jason Low
2014-04-10 17:28 ` Peter Zijlstra
2014-04-10 19:04 ` Jason Low
2014-04-10 23:26 ` Dave Jones
2014-04-10 23:30 ` Dave Jones
2014-04-11 3:48 ` Paul E. McKenney
2014-04-11 13:41 ` Michael L. Semon
2014-04-10 8:12 ` Peter Zijlstra
2014-04-10 8:13 ` Peter Zijlstra
2014-04-10 14:29 ` cred_guard_mutex vs seq_file::lock [was: Re: 3.14.0+/x86: lockdep and mutexes not getting along] Peter Zijlstra
2014-04-11 14:50 ` David Howells
2014-04-11 15:07 ` Al Viro
2014-07-30 22:31 ` Kirill A. Shutemov
2014-07-30 23:03 ` Kirill A. Shutemov
2014-07-31 7:26 ` Cyrill Gorcunov
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=20140410141559.GE13658@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=jason.low2@hp.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mlsemon35@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).