[tip/core/rcu,54/55] rcu: Make srcu_read_lock_held() call common lockdep-enabled function

Message ID 1315332049-2604-54-git-send-email-paulmck@linux.vnet.ibm.com
State New
Headers show

Commit Message

Paul E. McKenney Sept. 6, 2011, 6 p.m.
A common debug_lockdep_rcu_enabled() function is used to check whether
RCU lockdep splats should be reported, but srcu_read_lock() does not
use it.  This commit therefore brings srcu_read_lock_held() up to date.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
 include/linux/srcu.h |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

Comments

Josh Triplett Oct. 17, 2011, 2:03 a.m. | #1
On Tue, Sep 06, 2011 at 11:00:48AM -0700, Paul E. McKenney wrote:
> A common debug_lockdep_rcu_enabled() function is used to check whether
> RCU lockdep splats should be reported, but srcu_read_lock() does not
> use it.  This commit therefore brings srcu_read_lock_held() up to date.

Should this patch go before 53, or merge into 53, to prevent the issues
you describe from occuring in a tree which has 53 applied but not 54?

- Josh Triplett
Paul E. McKenney Oct. 24, 2011, 12:34 p.m. | #2
On Sun, Oct 16, 2011 at 07:03:10PM -0700, Josh Triplett wrote:
> On Tue, Sep 06, 2011 at 11:00:48AM -0700, Paul E. McKenney wrote:
> > A common debug_lockdep_rcu_enabled() function is used to check whether
> > RCU lockdep splats should be reported, but srcu_read_lock() does not
> > use it.  This commit therefore brings srcu_read_lock_held() up to date.
> 
> Should this patch go before 53, or merge into 53, to prevent the issues
> you describe from occuring in a tree which has 53 applied but not 54?

It is OK as is because the SRCU code does something reasonably sane
as is.  This is more about code cleanliness than about functionality.

							Thanx, Paul

Patch

diff --git a/include/linux/srcu.h b/include/linux/srcu.h
index fcbaee7..54a70b7 100644
--- a/include/linux/srcu.h
+++ b/include/linux/srcu.h
@@ -84,6 +84,9 @@  long srcu_batches_completed(struct srcu_struct *sp);
  * this assumes we are in an SRCU read-side critical section unless it can
  * prove otherwise.
  *
+ * Checks debug_lockdep_rcu_enabled() to prevent false positives during boot
+ * and while lockdep is disabled.
+ *
  * Note that if the CPU is in an extended quiescent state, for example,
  * if the CPU is in dyntick-idle mode, then rcu_read_lock_held() returns
  * false even if the CPU did an rcu_read_lock().  The reason for this is
@@ -96,7 +99,7 @@  long srcu_batches_completed(struct srcu_struct *sp);
  */
 static inline int srcu_read_lock_held(struct srcu_struct *sp)
 {
-	if (debug_locks)
+	if (!debug_lockdep_rcu_enabled())
 		return lock_is_held(&sp->dep_map);
 	if (rcu_check_extended_qs())
 		return 0;