[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tip-31a490e5c54f5499aa744f8524611e2a4b19f8ba@git.kernel.org>
Date: Mon, 3 Jun 2019 06:13:39 -0700
From: tip-bot for Yuyang Du <tipbot@...or.com>
To: linux-tip-commits@...r.kernel.org
Cc: duyuyang@...il.com, hpa@...or.com, mingo@...nel.org,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
peterz@...radead.org, tglx@...utronix.de
Subject: [tip:locking/core] locking/lockdep: Update comment
Commit-ID: 31a490e5c54f5499aa744f8524611e2a4b19f8ba
Gitweb: https://git.kernel.org/tip/31a490e5c54f5499aa744f8524611e2a4b19f8ba
Author: Yuyang Du <duyuyang@...il.com>
AuthorDate: Mon, 6 May 2019 16:19:27 +0800
Committer: Ingo Molnar <mingo@...nel.org>
CommitDate: Mon, 3 Jun 2019 11:55:44 +0200
locking/lockdep: Update comment
A leftover comment is removed. While at it, add more explanatory
comments. Such a trivial patch!
Signed-off-by: Yuyang Du <duyuyang@...il.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: bvanassche@....org
Cc: frederic@...nel.org
Cc: ming.lei@...hat.com
Cc: will.deacon@....com
Link: https://lkml.kernel.org/r/20190506081939.74287-12-duyuyang@gmail.com
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
kernel/locking/lockdep.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 6cf14c84eb6d..a9799f9ed093 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2811,10 +2811,16 @@ static int validate_chain(struct task_struct *curr,
* - is softirq-safe, if this lock is hardirq-unsafe
*
* And check whether the new lock's dependency graph
- * could lead back to the previous lock.
+ * could lead back to the previous lock:
*
- * any of these scenarios could lead to a deadlock. If
- * All validations
+ * - within the current held-lock stack
+ * - across our accumulated lock dependency records
+ *
+ * any of these scenarios could lead to a deadlock.
+ */
+ /*
+ * The simple case: does the current hold the same lock
+ * already?
*/
int ret = check_deadlock(curr, hlock, hlock->read);
Powered by blists - more mailing lists