Commit 8795d771 authored by Frederic Weisbecker's avatar Frederic Weisbecker

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: default avatarStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: David Miller <davem@davemloft.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
parent 868c522b
...@@ -2298,7 +2298,12 @@ void trace_hardirqs_on_caller(unsigned long ip) ...@@ -2298,7 +2298,12 @@ void trace_hardirqs_on_caller(unsigned long ip)
return; return;
if (unlikely(curr->hardirqs_enabled)) { 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; return;
} }
/* we'll do an OFF -> ON transition: */ /* we'll do an OFF -> ON transition: */
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment