On Wed, Aug 28, 2019 at 09:59:38AM -0400, Joel Fernandes wrote: > On Wed, Aug 28, 2019 at 03:14:33PM +0200, Sebastian Andrzej Siewior wrote: > > On 2019-08-28 05:54:26 [-0700], Paul E. McKenney wrote: > > > On Wed, Aug 28, 2019 at 11:27:39AM +0200, Sebastian Andrzej Siewior wrote: > > > > On 2019-08-27 08:53:06 [-0700], Paul E. McKenney wrote: > > > > > Am I understanding this correctly? > > > > > > > > Everything perfect except that it is not lockdep complaining but the > > > > WARN_ON_ONCE() in rcu_note_context_switch(). > > > > > > This one, right? > > > > > > WARN_ON_ONCE(!preempt && t->rcu_read_lock_nesting > 0); > > > > > > Another approach would be to change that WARN_ON_ONCE(). This fix might > > > be too extreme, as it would suppress other issues: > > > > > > WARN_ON_ONCE(IS_ENABLED(CONFIG_PREEMPT_RT_BASE) && !preempt && t->rcu_read_lock_nesting > 0); > > > > > > But maybe what is happening under the covers is that preempt is being > > > set when sleeping on a spinlock. Is that the case? > > > > I would like to keep that check and that is why we have: > > > > | #if defined(CONFIG_PREEMPT_RT_FULL) > > | sleeping_l = t->sleeping_lock; > > | #endif > > | WARN_ON_ONCE(!preempt && t->rcu_read_lock_nesting > 0 && !sleeping_l); > > > > in -RT and ->sleeping_lock is that counter that is incremented in > > spin_lock(). And the only reason why sleeping_lock_inc() was used in the > > patch was to disable _this_ warning. > > Makes sense, Sebastian. > > Paul, you meant "!" in front of the IS_ENABLED right in your code snippet right? > > The other issue with: > WARN_ON_ONCE(!IS_ENABLED(CONFIG_PREEMPT_RT_BASE) && !preempt && t->rcu_read_lock_nesting > 0); > > .. could be that, the warning will be disabled for -rt entirely, not just for > sleeping locks. And we probably do want to keep this warning for the cases in > -rt where we are blocking but it is not a sleeping lock. Right? Yes, my code was missing a "!", but I prefer Sebastian's and Scott's approach to mine anyway. ;-) Thanx, Paul
