Re: [Linux 2.6.29-rc2] BUG: using smp_processor_id() in preemptible

[Ingo Molnar]

* Rafael J. Wysocki <rjw@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/