From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: [RFC][PATCH 7/7] lockdep: Consider the rw_state of lock while validating the chain
Date: Sun, 17 Apr 2011 11:45:12 +0200 [thread overview]
Message-ID: <20110417095507.412301573@chello.nl> (raw)
In-Reply-To: 20110417094505.865828233@chello.nl
[-- Attachment #1: gautham_r_shenoy-lockdep-consider_the_rw_state_of_lock_while.patch --]
[-- Type: text/plain, Size: 4919 bytes --]
From: Gautham R Shenoy <ego@in.ibm.com>
Currently, while validating a particular dependency chain, we check if by
following the the locks_after list of current lock A, we can reach one of the
previous locks in the current chain.
i.e, if current chain is : A --> B --> C, then starting from C -->
locks_after, can we reach B.
However, if there are dependency chains:
C--> D --> Rlock(E)
Rlock(E) --> A,
where E is a Recursive Read lock, this chain cannot cause a deadlock because
of the recursive nature of E.
However, if the dependency chain was:
Wlock(E) --> A,
it could have caused a deadlock.
We solve this problem by defining conflicting states of each lock where:
Conflict(WRITE) = WRITE, READ, RECURSIVE_READ
Conflict(READ) = WRITE, READ
Conflict(RECURSIVE_READ) = WRITE
Thus, while traversing the locks_after chain of a particular lock A, we traverse
through only those entries in the chain where the state of the lock A in the
entry conflicts with the state of the lock A with which we started the
traversal.
Signed-off-by: Gautham R Shenoy <ego@in.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
kernel/lockdep.c | 43 ++++++++++++++++++++++++++++++++++++++++---
1 file changed, 40 insertions(+), 3 deletions(-)
Index: linux-2.6/kernel/lockdep.c
===================================================================
--- linux-2.6.orig/kernel/lockdep.c
+++ linux-2.6/kernel/lockdep.c
@@ -949,6 +949,26 @@ static inline int get_lock_depth(struct
return depth;
}
+/*
+ * Conflicting states:
+ * - A Recursive read conflicts only with a write.
+ * - A Non-recursive read can conflict with a non-recursive read and write.
+ * - A Write conflicts with Write, simple read and recursive read.
+ */
+
+#define get_rec_read_conflict(state) \
+ ((((is_write(state)) << (_RR_ - _W_))) & STATE_RECURSIVE_READ)
+
+#define get_simple_read_conflict(state) \
+ (((((is_write(state)) << (_R_ - _W_))) | (is_simple_read(state))) \
+ & STATE_READ)
+#define get_write_conflict(state) STATE_WRITE
+
+#define get_lock_conflict_states(state) \
+ (get_rec_read_conflict(state) | \
+ get_simple_read_conflict(state) | \
+ get_write_conflict(state))
+
static int __bfs(struct lock_list *source_entry,
void *data,
int (*match)(struct lock_list *entry, void *data),
@@ -958,6 +978,7 @@ static int __bfs(struct lock_list *sourc
struct lock_list *entry;
struct list_head *head;
struct circular_queue *cq = &lock_cq;
+ unsigned int conflict;
int ret = 1;
if (match(source_entry, data)) {
@@ -992,9 +1013,13 @@ static int __bfs(struct lock_list *sourc
else
head = &lock->dep_class->locks_before;
+ conflict = get_lock_conflict_states(lock->dep_lock_rw_state);
+
list_for_each_entry(entry, head, entry) {
if (!lock_accessed(entry)) {
unsigned int cq_depth;
+ if (!(entry->this_lock_rw_state & conflict))
+ continue;
mark_lock_accessed(entry, lock);
if (match(entry, data)) {
*target_entry = entry;
@@ -1411,8 +1436,9 @@ check_usage(struct task_struct *curr, st
struct lock_list *uninitialized_var(target_entry1);
this.parent = NULL;
-
this.dep_class = hlock_class(prev);
+ this.this_lock_rw_state = next->rw_state;
+ this.dep_lock_rw_state = prev->rw_state;
ret = find_usage_backwards(&this, bit_backwards, &target_entry);
if (ret < 0)
return print_bfs_bug(ret);
@@ -1421,6 +1447,8 @@ check_usage(struct task_struct *curr, st
that.parent = NULL;
that.dep_class = hlock_class(next);
+ that.this_lock_rw_state = prev->rw_state;
+ that.dep_lock_rw_state = next->rw_state;
ret = find_usage_forwards(&that, bit_forwards, &target_entry1);
if (ret < 0)
return print_bfs_bug(ret);
@@ -1663,6 +1691,8 @@ check_prev_add(struct task_struct *curr,
*/
this.dep_class = hlock_class(next);
this.parent = NULL;
+ this.this_lock_rw_state = prev->rw_state;
+ this.dep_lock_rw_state = next->rw_state;
ret = check_noncircular(&this, hlock_class(prev), &target_entry);
if (unlikely(!ret))
return print_circular_bug(&this, target_entry, next, prev);
@@ -1776,7 +1806,8 @@ check_prevs_add(struct task_struct *curr
* Only non-recursive-read entries get new dependencies
* added:
*/
- if (!is_rec_read(hlock->rw_state)) {
+ if (!is_rec_read(hlock->rw_state) ||
+ is_first_rec_read(hlock->rw_state)) {
if (!check_prev_add(curr, hlock, next,
distance, trylock_loop))
return 0;
@@ -1950,9 +1981,15 @@ static int validate_chain(struct task_st
if (!ret)
return 0;
+
+ if (ret != 2 && is_rec_read(hlock->rw_state))
+ hlock->rw_state |= STATE_FIRST_RECURSIVE_READ;
+
+
/*
* Add dependency only if this lock is not the head
- * of the chain, and if it's not a secondary read-lock:
+ * of the chain, and if it's not the first instance of
+ * the recursive read-lock:
*/
if (!chain_head && ret != 2)
if (!check_prevs_add(curr, hlock))
next prev parent reply other threads:[~2011-04-17 9:58 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-17 9:45 [RFC][PATCH 0/7] lockdep: Support recurise-read locks Peter Zijlstra
2011-04-17 9:45 ` [RFC][PATCH 1/7] lockdep: Implement extra recursive-read lock tests Peter Zijlstra
2011-04-17 9:45 ` [RFC][PATCH 2/7] lockdep: Remove redundant read checks Peter Zijlstra
2011-04-18 14:28 ` Steven Rostedt
2011-04-17 9:45 ` [RFC][PATCH 3/7] lockdep: Annotate read/write states Peter Zijlstra
2011-04-18 13:34 ` Yong Zhang
2011-04-18 16:34 ` Steven Rostedt
2011-04-18 16:36 ` Peter Zijlstra
2011-04-18 16:26 ` Steven Rostedt
2011-04-18 16:27 ` Steven Rostedt
2011-04-18 16:31 ` Steven Rostedt
2011-04-17 9:45 ` [RFC][PATCH 4/7] lockdep: Seperate lock ids for read/write acquires Peter Zijlstra
2011-04-18 16:46 ` Steven Rostedt
2011-04-18 16:49 ` Peter Zijlstra
2011-04-18 17:33 ` Steven Rostedt
2011-04-18 22:07 ` Peter Zijlstra
2011-04-17 9:45 ` [RFC][PATCH 5/7] lockdep: Rename lock_list::class Peter Zijlstra
2011-04-17 9:45 ` [RFC][PATCH 6/7] lockdep: Maintain rw_state entries in locklist Peter Zijlstra
2011-04-18 13:37 ` Yong Zhang
2011-04-17 9:45 ` Peter Zijlstra [this message]
2011-04-18 3:41 ` [RFC][PATCH 0/7] lockdep: Support recurise-read locks Tetsuo Handa
2011-04-22 7:19 ` Yong Zhang
2011-04-22 7:27 ` Yong Zhang
2011-04-22 7:44 ` Tetsuo Handa
2011-04-22 8:01 ` Yong Zhang
2011-04-22 8:31 ` Tetsuo Handa
2011-04-22 8:59 ` Yong Zhang
2011-04-22 9:19 ` Tetsuo Handa
2011-04-23 12:33 ` [PATCH] lockdep: ignore cached chain key for recursive read Yong Zhang
2011-04-23 13:04 ` Tetsuo Handa
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=20110417095507.412301573@chello.nl \
--to=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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