Skip to contentSkip to conversation

lockdep: Fix wrong assumption in match_held_lock

tip:core/urgent tip-bot for Peter Zijlstra 2 participants 5 messages Aug 9, 2011 – Aug 10, 2011 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): 1312547787.28695.2.camel@twins

#1 lore raw
Commit-ID:  80e0401e35410a69bfae05b454db8a7187edd6b8
Gitweb:     http://git.kernel.org/tip/80e0401e35410a69bfae05b454db8a7187edd6b8
Author:     Peter Zijlstra <[email protected]>
AuthorDate: Fri, 5 Aug 2011 14:26:17 +0200
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 9 Aug 2011 11:57:35 +0200

lockdep: Fix wrong assumption in match_held_lock

match_held_lock() was assuming it was being called on a lock class that had already seen usage.

This condition was true for bug-free code using lockdep_assert_held(), since you're in fact holding the lock when calling it. However the assumption fails the moment you assume the assertion can fail, which is the whole point of having the assertion in the first place.

Anyway, now that there's more lockdep_is_held() users, notably __rcu_dereference_check(), its much easier to trigger this since we test for a number of locks and we only need to hold any one of them to be good.

---
 kernel/lockdep.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)
kernel/lockdep.c +7 -1
index 8c24294..91d67ce 100644
@@ -3111,7 +3111,13 @@ static int match_held_lock(struct held_lock *hlock, struct lockdep_map *lock)
 		if (!class)
 			class = look_up_lock_class(lock, 0);
 
-		if (DEBUG_LOCKS_WARN_ON(!class))
+		/*
+		 * If look_up_lock_class() failed to find a class, we're trying
+		 * to test if we hold a lock that has never yet been acquired.
+		 * Clearly if the lock hasn't been acquired _ever_, we're not
+		 * holding it either, so report failure.
+		 */
+		if (!class)
 			return 0;
 
 		if (DEBUG_LOCKS_WARN_ON(!hlock->nest_lock))
#2 lore raw
Quoted 17 lines · tip-bot for Peter Zijlstra
Commit-ID:  80e0401e35410a69bfae05b454db8a7187edd6b8
Gitweb:     http://git.kernel.org/tip/80e0401e35410a69bfae05b454db8a7187edd6b8
Author:     Peter Zijlstra <[email protected]>
AuthorDate: Fri, 5 Aug 2011 14:26:17 +0200
Committer:  Ingo Molnar <[email protected]>
CommitDate: Tue, 9 Aug 2011 11:57:35 +0200

lockdep: Fix wrong assumption in match_held_lock

match_held_lock() was assuming it was being called on a lock class that had already seen usage.

This condition was true for bug-free code using lockdep_assert_held(), since you're in fact holding the lock when calling it. However the assumption fails the moment you assume the assertion can fail, which is the whole point of having the assertion in the first place.

Quoted 8 lines

Anyway, now that there's more lockdep_is_held() users, notably __rcu_dereference_check(), its much easier to trigger this since we test for a number of locks and we only need to hold any one of them to be good.

BTW, I can't open this link.

Thanks,
Yong

#3 lore raw
Quoted 3 lines · Yong Zhang
Quoted 1 line

BTW, I can't open this link.

Gah! I did mess that up, but I've no idea how though, I usually copy/paste or let my script do it, in case of copy/paste one would assume I picked the wrong msg, but a grep through my sent folder doesn't find any email with that msgid.. and my script isn't imaginative enough to just make one up like that. Anyway:

lkml.kernel.org/r/1312969382.23148.1.camel@twins

should be the actual link, however that doesn't appear to work either, included the relevant headers of the actual email:

---

Subject: Re: select_task_rq_fair: WARNING: at kernel/lockdep.c match_held_lock
From: Peter Zijlstra <[email protected]>
To: Sergey Senozhatsky <[email protected]>
Cc: Ingo Molnar <[email protected]>, Thomas Gleixner <[email protected]>,
Andrew Morton <[email protected]>, [email protected], KAMEZAWA Hiroyuki <[email protected]>, [email protected]
Date: Fri, 05 Aug 2011 14:36:20 +0200
In-Reply-To: <[email protected]>
References: <[email protected]>

         <1312470358.16729.25.camel@twins>
         <[email protected]>
         <1312472867.16729.38.camel@twins>
         <[email protected]>

Message-ID: <1312969382.23148.1.camel@twins>

#4 lore raw
Quoted 28 lines · Peter Zijlstra
Quoted 3 lines · Yong Zhang
Quoted 1 line

BTW, I can't open this link.

Gah! I did mess that up, but I've no idea how though, I usually copy/paste or let my script do it, in case of copy/paste one would assume I picked the wrong msg, but a grep through my sent folder doesn't find any email with that msgid.. and my script isn't imaginative enough to just make one up like that. Anyway:

lkml.kernel.org/r/1312969382.23148.1.camel@twins

should be the actual link, however that doesn't appear to work either, included the relevant headers of the actual email:

---

Subject: Re: select_task_rq_fair: WARNING: at kernel/lockdep.c match_held_lock
From: Peter Zijlstra <[email protected]>
To: Sergey Senozhatsky <[email protected]>
Cc: Ingo Molnar <[email protected]>, Thomas Gleixner <[email protected]>,
Andrew Morton <[email protected]>, [email protected], KAMEZAWA Hiroyuki <[email protected]>, [email protected]
Date: Fri, 05 Aug 2011 14:36:20 +0200
In-Reply-To: <[email protected]>
References: <[email protected]>

Quoted 6 lines
         <1312470358.16729.25.camel@twins>
         <[email protected]>
         <1312472867.16729.38.camel@twins>
         <[email protected]>

Message-ID: <1312969382.23148.1.camel@twins>

The actual one showed in maillist is like below:
---
Subject: Re: select_task_rq_fair: WARNING: at kernel/lockdep.c
match_held_lock
From: Peter Zijlstra <[email protected]>
To: Sergey Senozhatsky <[email protected]>
Cc: Ingo Molnar <[email protected]>, Thomas Gleixner <[email protected]>,
Andrew Morton <[email protected]>, [email protected],
KAMEZAWA Hiroyuki <[email protected]>, [email protected]
Date: Fri, 05 Aug 2011 14:36:20 +0200
In-Reply-To: <[email protected]>
References: <[email protected]>

         <1312470358.16729.25.camel@twins>
         <[email protected]>
         <1312472867.16729.38.camel@twins>
         <[email protected]>

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
X-Mailer: Evolution 3.0.2-
Message-ID: <1312547780.28695.1.camel@twins>
---

Not sure how the difference happens.

Thanks,
Yong

#5 lore raw
Quoted 34 lines · Yong Zhang
Quoted 33 lines · Peter Zijlstra
Quoted 3 lines · Yong Zhang
Quoted 1 line

BTW, I can't open this link.

Gah! I did mess that up, but I've no idea how though, I usually copy/paste or let my script do it, in case of copy/paste one would assume I picked the wrong msg, but a grep through my sent folder doesn't find any email with that msgid.. and my script isn't imaginative enough to just make one up like that. Anyway:

lkml.kernel.org/r/1312969382.23148.1.camel@twins

should be the actual link, however that doesn't appear to work either, included the relevant headers of the actual email:

---

Subject: Re: select_task_rq_fair: WARNING: at kernel/lockdep.c match_held_lock
From: Peter Zijlstra <[email protected]>
To: Sergey Senozhatsky <[email protected]>
Cc: Ingo Molnar <[email protected]>, Thomas Gleixner <[email protected]>,
Andrew Morton <[email protected]>, [email protected], KAMEZAWA Hiroyuki <[email protected]>, [email protected]
Date: Fri, 05 Aug 2011 14:36:20 +0200
In-Reply-To: <[email protected]>
References: <[email protected]>

         <1312470358.16729.25.camel@twins>
         <[email protected]>
         <1312472867.16729.38.camel@twins>
         <[email protected]>
Quoted 3 lines
Quoted 1 line

Message-ID: <1312969382.23148.1.camel@twins>

The actual one showed in maillist is like below:

Hmm, you have mentioned it :)

Quoted 27 lines

---
Subject: Re: select_task_rq_fair: WARNING: at kernel/lockdep.c
match_held_lock
From: Peter Zijlstra <[email protected]>
To: Sergey Senozhatsky <[email protected]>
Cc: Ingo Molnar <[email protected]>, Thomas Gleixner <[email protected]>,
Andrew Morton <[email protected]>, [email protected],
KAMEZAWA Hiroyuki <[email protected]>, [email protected]
Date: Fri, 05 Aug 2011 14:36:20 +0200
In-Reply-To: <[email protected]>
References: <[email protected]>

         <1312470358.16729.25.camel@twins>
         <[email protected]>
         <1312472867.16729.38.camel@twins>
         <[email protected]>

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
X-Mailer: Evolution 3.0.2-
Message-ID: <1312547780.28695.1.camel@twins>
---

Not sure how the difference happens.

Thanks,
Yong