[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190628091528.17059-7-duyuyang@gmail.com>
Date: Fri, 28 Jun 2019 17:15:04 +0800
From: Yuyang Du <duyuyang@...il.com>
To: peterz@...radead.org, will.deacon@....com, mingo@...nel.org
Cc: bvanassche@....org, ming.lei@...hat.com, frederic@...nel.org,
tglx@...utronix.de, linux-kernel@...r.kernel.org,
longman@...hat.com, paulmck@...ux.vnet.ibm.com,
boqun.feng@...il.com, Yuyang Du <duyuyang@...il.com>
Subject: [PATCH v3 06/30] locking/lockdep: Update comments in struct lock_list and held_lock
The comments regarding initial chain key and BFS are outdated so update them.
Signed-off-by: Yuyang Du <duyuyang@...il.com>
---
include/linux/lockdep.h | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 3c6fb63..5e0a1a9 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -198,8 +198,7 @@ struct lock_list {
int distance;
/*
- * The parent field is used to implement breadth-first search, and the
- * bit 0 is reused to indicate if the lock has been accessed in BFS.
+ * The parent field is used to implement breadth-first search.
*/
struct lock_list *parent;
};
@@ -242,7 +241,7 @@ struct held_lock {
* as likely as possible - hence the 64-bit width.
*
* The task struct holds the current hash value (initialized
- * with zero), here we store the previous hash value:
+ * with INITIAL_CHAIN_KEY), here we store the previous hash value:
*/
u64 prev_chain_key;
unsigned long acquire_ip;
@@ -261,12 +260,12 @@ struct held_lock {
/*
* The lock-stack is unified in that the lock chains of interrupt
* contexts nest ontop of process context chains, but we 'separate'
- * the hashes by starting with 0 if we cross into an interrupt
- * context, and we also keep do not add cross-context lock
- * dependencies - the lock usage graph walking covers that area
- * anyway, and we'd just unnecessarily increase the number of
- * dependencies otherwise. [Note: hardirq and softirq contexts
- * are separated from each other too.]
+ * the hashes by starting with a new chain if we cross into an
+ * interrupt context, and we also keep not adding cross-context
+ * lock dependencies - the lock usage graph walking covers that
+ * area anyway, and we'd just unnecessarily increase the number
+ * of dependencies otherwise. [Note: hardirq and softirq
+ * contexts are separated from each other too.]
*
* The following field is used to detect when we cross into an
* interrupt context:
--
1.8.3.1
Powered by blists - more mailing lists