linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Boqun Feng <boqun.feng@gmail.com>, Qian Cai <cai@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@kernel.org>, x86 <x86@kernel.org>,
	linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [tip: locking/core] lockdep: Fix lockdep recursion
Date: Tue, 13 Oct 2020 13:25:44 +0200	[thread overview]
Message-ID: <20201013112544.GZ2628@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20201013104450.GQ2651@hirez.programming.kicks-ass.net>

On Tue, Oct 13, 2020 at 12:44:50PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 13, 2020 at 12:34:06PM +0200, Peter Zijlstra wrote:
> > On Mon, Oct 12, 2020 at 02:28:12PM -0700, Paul E. McKenney wrote:
> > > It is certainly an accident waiting to happen.  Would something like
> > > the following make sense?
> > 
> > Sadly no.
> > 
> > > ------------------------------------------------------------------------
> > > 
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index bfd38f2..52a63bc 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -4067,6 +4067,7 @@ void rcu_cpu_starting(unsigned int cpu)
> > >  
> > >  	rnp = rdp->mynode;
> > >  	mask = rdp->grpmask;
> > > +	lockdep_off();
> > >  	raw_spin_lock_irqsave_rcu_node(rnp, flags);
> > >  	WRITE_ONCE(rnp->qsmaskinitnext, rnp->qsmaskinitnext | mask);
> > >  	newcpu = !(rnp->expmaskinitnext & mask);
> > > @@ -4086,6 +4087,7 @@ void rcu_cpu_starting(unsigned int cpu)
> > >  	} else {
> > >  		raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> > >  	}
> > > +	lockdep_on();
> > >  	smp_mb(); /* Ensure RCU read-side usage follows above initialization. */
> > >  }
> > 
> > This will just shut it up, but will not fix the actual problem of that
> > spin-lock ending up in trace_lock_acquire() which relies on RCU which
> > isn't looking.
> > 
> > What we need here is to supress tracing not lockdep. Let me consider.
> 
> We appear to have a similar problem with rcu_report_dead(), it's
> raw_spin_unlock()s can end up in trace_lock_release() while we just
> killed RCU.

So we can deal with the explicit trace_*() calls like the below, but I
really don't like it much. It also doesn't help with function tracing.
This is really early/late in the hotplug cycle and should be considered
entry, we shouldn't be tracing anything here.

Paul, would it be possible to use a scheme similar to IRQ/NMI for
hotplug? That seems to mostly rely on atomic ops, not locks.

---
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index d05db575f60f..22e3a3523ad3 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -159,7 +159,7 @@ extern void lockdep_init_task(struct task_struct *task);
  */
 #define LOCKDEP_RECURSION_BITS	16
 #define LOCKDEP_OFF		(1U << LOCKDEP_RECURSION_BITS)
-#define LOCKDEP_RECURSION_MASK	(LOCKDEP_OFF - 1)
+#define LOCKDEP_TRACE_MASK	(LOCKDEP_OFF - 1)
 
 /*
  * lockdep_{off,on}() are macros to avoid tracing and kprobes; not inlines due
@@ -176,6 +176,16 @@ do {							\
 	current->lockdep_recursion -= LOCKDEP_OFF;	\
 } while (0)
 
+#define lockdep_trace_off()				\
+do {							\
+	current->lockdep_recursion++;			\
+} while (0)
+
+#define lockdep_trace_on()				\
+do {							\
+	current->lockdep_recursion--			\
+} while (0)
+
 extern void lockdep_register_key(struct lock_class_key *key);
 extern void lockdep_unregister_key(struct lock_class_key *key);
 
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 3e99dfef8408..2df98abee82e 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -87,7 +87,7 @@ static inline bool lockdep_enabled(void)
 	if (raw_cpu_read(lockdep_recursion))
 		return false;
 
-	if (current->lockdep_recursion)
+	if (current->lockdep_recursion >> LOCKDEP_RECURSION_BITS)
 		return false;
 
 	return true;
@@ -5410,7 +5410,8 @@ void lock_acquire(struct lockdep_map *lock, unsigned int subclass,
 {
 	unsigned long flags;
 
-	trace_lock_acquire(lock, subclass, trylock, read, check, nest_lock, ip);
+	if (!(current->lockdep_recursion & LOCKDEP_TRACE_MASK))
+		trace_lock_acquire(lock, subclass, trylock, read, check, nest_lock, ip);
 
 	if (!debug_locks)
 		return;
@@ -5450,7 +5451,8 @@ void lock_release(struct lockdep_map *lock, unsigned long ip)
 {
 	unsigned long flags;
 
-	trace_lock_release(lock, ip);
+	if (!(current->lockdep_recursion & LOCKDEP_TRACE_MASK))
+		trace_lock_release(lock, ip);
 
 	if (unlikely(!lockdep_enabled()))
 		return;
@@ -5662,7 +5664,8 @@ void lock_contended(struct lockdep_map *lock, unsigned long ip)
 {
 	unsigned long flags;
 
-	trace_lock_acquired(lock, ip);
+	if (!(current->lockdep_recursion & LOCKDEP_TRACE_MASK))
+		trace_lock_acquired(lock, ip);
 
 	if (unlikely(!lock_stat || !lockdep_enabled()))
 		return;
@@ -5680,7 +5683,8 @@ void lock_acquired(struct lockdep_map *lock, unsigned long ip)
 {
 	unsigned long flags;
 
-	trace_lock_contended(lock, ip);
+	if (!(current->lockdep_recursion & LOCKDEP_TRACE_MASK))
+		trace_lock_contended(lock, ip);
 
 	if (unlikely(!lock_stat || !lockdep_enabled()))
 		return;
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index edeabc232c21..dbd56603fc0a 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -4047,6 +4047,11 @@ void rcu_cpu_starting(unsigned int cpu)
 
 	rnp = rdp->mynode;
 	mask = rdp->grpmask;
+
+	/*
+	 * Lockdep will call tracing, which requires RCU, but RCU isn't on yet.
+	 */
+	lockdep_trace_off();
 	raw_spin_lock_irqsave_rcu_node(rnp, flags);
 	WRITE_ONCE(rnp->qsmaskinitnext, rnp->qsmaskinitnext | mask);
 	newcpu = !(rnp->expmaskinitnext & mask);
@@ -4064,6 +4069,7 @@ void rcu_cpu_starting(unsigned int cpu)
 	} else {
 		raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
 	}
+	lockdep_trace_on();
 	smp_mb(); /* Ensure RCU read-side usage follows above initialization. */
 }
 
@@ -4091,6 +4097,11 @@ void rcu_report_dead(unsigned int cpu)
 
 	/* Remove outgoing CPU from mask in the leaf rcu_node structure. */
 	mask = rdp->grpmask;
+
+	/*
+	 * Lockdep will call tracing, which requires RCU, but we're switching RCU off.
+	 */
+	lockdep_trace_off();
 	raw_spin_lock(&rcu_state.ofl_lock);
 	raw_spin_lock_irqsave_rcu_node(rnp, flags); /* Enforce GP memory-order guarantee. */
 	rdp->rcu_ofl_gp_seq = READ_ONCE(rcu_state.gp_seq);
@@ -4101,8 +4112,10 @@ void rcu_report_dead(unsigned int cpu)
 		raw_spin_lock_irqsave_rcu_node(rnp, flags);
 	}
 	WRITE_ONCE(rnp->qsmaskinitnext, rnp->qsmaskinitnext & ~mask);
+	/* RCU is off, locks must not call into tracing */
 	raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
 	raw_spin_unlock(&rcu_state.ofl_lock);
+	lockdep_trace_on();
 
 	rdp->cpu_started = false;
 }
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 39334d2d2b37..403b138f7cd4 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -275,8 +275,8 @@ EXPORT_SYMBOL_GPL(rcu_callback_map);
 
 noinstr int notrace debug_lockdep_rcu_enabled(void)
 {
-	return rcu_scheduler_active != RCU_SCHEDULER_INACTIVE && debug_locks &&
-	       current->lockdep_recursion == 0;
+	return rcu_scheduler_active != RCU_SCHEDULER_INACTIVE && __lockdep_enabled;
+
 }
 EXPORT_SYMBOL_GPL(debug_lockdep_rcu_enabled);
 

  reply	other threads:[~2020-10-13 11:26 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <160223032121.7002.1269740091547117869.tip-bot2@tip-bot2>
2020-10-09 13:41 ` [tip: locking/core] lockdep: Fix lockdep recursion Qian Cai
2020-10-09 13:58   ` Paul E. McKenney
2020-10-09 15:30     ` Qian Cai
2020-10-09 16:11       ` Paul E. McKenney
2020-10-09 16:23     ` Peter Zijlstra
2020-10-09 16:37       ` Paul E. McKenney
2020-10-09 17:36       ` Qian Cai
2020-10-09 17:50         ` Paul E. McKenney
2020-10-09 17:54         ` Qian Cai
2020-10-09 18:21           ` Paul E. McKenney
2020-10-12  3:11   ` Boqun Feng
2020-10-12 14:14     ` Qian Cai
2020-10-12 21:28     ` Paul E. McKenney
2020-10-13 10:34       ` Peter Zijlstra
2020-10-13 10:44         ` Peter Zijlstra
2020-10-13 11:25           ` Peter Zijlstra [this message]
2020-10-13 16:26             ` Paul E. McKenney
2020-10-13 19:30               ` Paul E. McKenney
2020-10-14 18:34                 ` Paul E. McKenney
2020-10-14 21:53                   ` Peter Zijlstra
2020-10-14 22:11                     ` Paul E. McKenney
2020-10-14 22:39                       ` Peter Zijlstra
2020-10-14 23:55                         ` Paul E. McKenney
2020-10-15  3:41                           ` Paul E. McKenney
2020-10-15  9:49                             ` Peter Zijlstra
2020-10-15  9:50                               ` Peter Zijlstra
2020-10-15 16:15                                 ` Paul E. McKenney
2020-10-15  9:52                               ` Peter Zijlstra
2020-10-15 16:20                                 ` Paul E. McKenney
2020-10-15 16:15                               ` Paul E. McKenney
2020-10-15 17:23                                 ` Paul E. McKenney
2020-10-13 16:15           ` Paul E. McKenney
2020-10-13 10:27     ` Peter Zijlstra
2020-10-13 16:24       ` Boqun Feng
2020-10-27 19:31     ` Qian Cai
2020-10-28  3:01       ` Paul E. McKenney
2020-10-28 14:39         ` Qian Cai
2020-10-28 15:53           ` Paul E. McKenney
2020-10-28 20:08             ` Qian Cai
2020-10-28 21:02               ` Paul E. McKenney

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=20201013112544.GZ2628@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=boqun.feng@gmail.com \
    --cc=cai@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sfr@canb.auug.org.au \
    --cc=x86@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).