lockdep: Fix redundant_hardirqs_on incremented with irqs enabled
When a path restore the flags while irqs are already enabled, we update the per cpu var redundant_hardirqs_on in a racy fashion and debug_atomic_inc() warns about this situation. In this particular case, loosing a few hits in a stat is not a big deal, so increment it without protection. v2: Don't bother with disabling irq, we can miss one count in rare situations Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: David Miller <davem@davemloft.net> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This commit is contained in:
parent
868c522b1b
commit
8795d7717c
|
@ -2298,7 +2298,12 @@ void trace_hardirqs_on_caller(unsigned long ip)
|
|||
return;
|
||||
|
||||
if (unlikely(curr->hardirqs_enabled)) {
|
||||
debug_atomic_inc(redundant_hardirqs_on);
|
||||
/*
|
||||
* Neither irq nor preemption are disabled here
|
||||
* so this is racy by nature but loosing one hit
|
||||
* in a stat is not a big deal.
|
||||
*/
|
||||
this_cpu_inc(lockdep_stats.redundant_hardirqs_on);
|
||||
return;
|
||||
}
|
||||
/* we'll do an OFF -> ON transition: */
|
||||
|
|
Loading…
Reference in New Issue