On Thu, Apr 15, 2010 at 04:03:58PM +0200, Ingo Molnar wrote: > > In this case, I guess the following fix should be sufficient? > > I'm going to test it and provide a sane changelog. > > > > > > diff --git a/kernel/lockdep.c b/kernel/lockdep.c > > index 78325f8..65d4336 100644 > > --- a/kernel/lockdep.c > > +++ b/kernel/lockdep.c > > @@ -2298,7 +2298,11 @@ void trace_hardirqs_on_caller(unsigned long ip) > > return; > > > > if (unlikely(curr->hardirqs_enabled)) { > > + unsigned long flags; > > + > > + raw_local_irq_save(flags); > > debug_atomic_inc(redundant_hardirqs_on); > > + raw_local_irq_restore(flags); > > return; > > } > > /* we'll do an OFF -> ON transition: */ > > that looks rather ugly. Why not do a raw: > > this_cpu_inc(lockdep_stats.redundant_hardirqs_on); > > which basically open-codes debug_atomic_inc(), but without the warning? Because that would open a race against interrupts that might touch lockdep_stats.redundant_hardirqs_on too. If you think it's not very important (this race must be pretty rare I guess), I can use your solution. > > Btw., using the this_cpu() methods might result in faster code for all the > debug_atomic_inc() macros as well? Indeed, will change that too. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html