Messages in this thread | | | Date | Mon, 26 Jan 2009 22:35:19 +0100 | From | Ingo Molnar <> | Subject | Re: [Linux 2.6.29-rc2] BUG: using smp_processor_id() in preemptible |
| |
* Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Monday 26 January 2009, Ingo Molnar wrote: [...] > > It would work like this, you could mark IRQs as disabled 'permanently': > > > > force_irqs_off_start(); > > ... > > force_irqs_off_end(); > > > > you could mark an arbitrarily complex code sequence that way, and ftrace > > would emit a WARN_ONCE() if irqs are enable anytime during that sequence - > > by using the irq-tracking facilities we have for the irqsoff tracer (and > > which we also have for lockdep). > > > > Would that be useful? > > Not sure, I only know a little about ftrace, I really can't judge.
The instrumentation is really simple, see kernel/tracing/trace_irqsoff.c:
we call this function if hardirqs are disabled anywhere in the kernel:
static inline void start_critical_timing(unsigned long ip, unsigned long parent_ip)
and we call this function if hardirqs are enabled anywhere in the kernel:
static inline void stop_critical_timing(unsigned long ip, unsigned long parent_ip)
that's all. You need a single line check in stop_critical_timing(), something like this:
WARN_ON_ONCE(per_cpu(hardirqs_forced_off, this_cpu));
> Anyway, I think that putting the checks directly into the code path in > question would be more reliable and would still work without ftrace.
More reliable than a WARN() triggering right at the buggy place that erroneously enables IRQs? Regardless of how obscurely it's done - whether it's a side effect of something, etc. etc.?
With such a generic facility you'd not have to put in any explicit checks anywhere _at all_.
In fact whatever check you put in it's _always_ going to be fundamentally more fragile than direct instrumentation: you cannot possibly check all possible places that enable interrupts. (they could be disabling interrupts as a _restore_irqs() sequence for example)
Ingo
| |