Message ID | 1270552321.1595.42.camel@laptop |
---|---|
State | RFC |
Delegated to: | David Miller |
Headers | show |
From: Peter Zijlstra <peterz@infradead.org> Date: Tue, 06 Apr 2010 13:12:01 +0200 > One thing we can do is make the code WARN about this, how about > something like the below It's going to warn every bootup in cpu_clock() on x86. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2010-04-06 at 04:13 -0700, David Miller wrote: > From: Peter Zijlstra <peterz@infradead.org> > Date: Tue, 06 Apr 2010 13:12:01 +0200 > > > One thing we can do is make the code WARN about this, how about > > something like the below > > It's going to warn every bootup in cpu_clock() on x86. *sigh*, yes, we could hack around that I suppose.. it would be nice to automate this check though, I bet you don't fancy tracking down more such splats than you have to. You could of course insert the debug code into your arch routines but that would limit the coverage checks to whatever you happen to run. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Peter Zijlstra <peterz@infradead.org> Date: Tue, 06 Apr 2010 13:20:19 +0200 > On Tue, 2010-04-06 at 04:13 -0700, David Miller wrote: >> From: Peter Zijlstra <peterz@infradead.org> >> Date: Tue, 06 Apr 2010 13:12:01 +0200 >> >> > One thing we can do is make the code WARN about this, how about >> > something like the below >> >> It's going to warn every bootup in cpu_clock() on x86. > > *sigh*, yes, we could hack around that I suppose.. it would be nice to > automate this check though, I bet you don't fancy tracking down more > such splats than you have to. > > You could of course insert the debug code into your arch routines but > that would limit the coverage checks to whatever you happen to run. Yes, f.e. you could add local_irq_*_nmi() or similar that don't complain when called inside of an NMI. I would certainly welcome this debugging facility, for sure! It would have saved me two days of work this time, in fact. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/kernel/lockdep.c b/kernel/lockdep.c index 08e6f76..06ec1c7 100644 --- a/kernel/lockdep.c +++ b/kernel/lockdep.c @@ -2341,6 +2341,11 @@ EXPORT_SYMBOL(trace_hardirqs_on_caller); void trace_hardirqs_on(void) { + /* + * Some architectures can't deal with local_irq_{enable,disable} + * from NMI context (SPARC), enforce this. + */ + WARN_ON_ONCE(in_nmi()); trace_hardirqs_on_caller(CALLER_ADDR0); } EXPORT_SYMBOL(trace_hardirqs_on); @@ -2375,6 +2380,11 @@ EXPORT_SYMBOL(trace_hardirqs_off_caller); void trace_hardirqs_off(void) { + /* + * Some architectures can't deal with local_irq_{enable,disable} + * from NMI context (SPARC), enforce this. + */ + WARN_ON_ONCE(in_nmi()); trace_hardirqs_off_caller(CALLER_ADDR0); } EXPORT_SYMBOL(trace_hardirqs_off);