Messages in this thread | | | Date | Wed, 21 Oct 2020 11:27:57 -0400 | From | Steven Rostedt <> | Subject | Re: BUG: using __this_cpu_read() in preemptible code in trace_hardirqs_on |
| |
On Wed, 21 Oct 2020 17:12:37 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
> > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > > > index 3e99dfef8408..9f818145ef7d 100644 > > > --- a/kernel/locking/lockdep.c > > > +++ b/kernel/locking/lockdep.c > > > @@ -4057,9 +4057,6 @@ void lockdep_hardirqs_on_prepare(unsigned long ip) > > > if (unlikely(in_nmi())) > > > return; > > > > > > - if (unlikely(__this_cpu_read(lockdep_recursion))) > > > - return; > > > - > > > if (unlikely(lockdep_hardirqs_enabled())) { > > > > Hmm, would moving the recursion check below the check of the > > lockdep_hardirqs_enable() cause a large skew in the spurious enable stats? > > May not be an issue, but something we should check to make sure that > > there's not a path that constantly hits this. > > Anything that sets recursion will have interrupts disabled.
It may have interrupts disabled, but does it have the hardirqs_enabled per_cpu variable set? The above check only looks at that, and doesn't check if interrupts are actually enabled.
For example, if lockdep is processing a mutex, it would set the recursion variable, but does it ever set the hardirqs_enabled variable to off?
-- Steve
| |