locking/lockdep: Fix a comment in add_chain_cache()
authorBart Van Assche <bvanassche@acm.org>
Thu, 14 Feb 2019 23:00:49 +0000 (15:00 -0800)
committerIngo Molnar <mingo@kernel.org>
Thu, 28 Feb 2019 06:55:45 +0000 (07:55 +0100)
Reflect that add_chain_cache() is always called with the graph lock held.

Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Waiman Long <longman@redhat.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: johannes.berg@intel.com
Cc: tj@kernel.org
Link: https://lkml.kernel.org/r/20190214230058.196511-15-bvanassche@acm.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
kernel/locking/lockdep.c

index 753a9b758266dd09b131c9a6bfe05d6efcafff5c..ec0cb794f70d175f3a26ed84aaecc30670568bb7 100644 (file)
@@ -2266,7 +2266,7 @@ static inline int add_chain_cache(struct task_struct *curr,
         */
 
        /*
-        * We might need to take the graph lock, ensure we've got IRQs
+        * The caller must hold the graph lock, ensure we've got IRQs
         * disabled to make this an IRQ-safe lock.. for recursion reasons
         * lockdep won't complain about its own locking errors.
         */