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

[Ingo Molnar]

* Rafael J. Wysocki <rjw@xxxxxxx> wrote:

> On Tuesday 27 January 2009, Ingo Molnar wrote:
> > 
> > * Rafael J. Wysocki <rjw@xxxxxxx> wrote:
> > 
> > > > 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)
> > > 
> > > In this particular case, I'm not really interested in that.  What I'm 
> > > interested in is which driver's ->suspend_late() or ->resume_early() (or 
> > > the equivalents for sysdevs) has enabled interrupts, which is quite easy 
> > > to check directly.
> > 
> > But this is exactly what it does - without any need for debug checks 
> > spread around!
> > 
> > You'll get a _full stack dump_ from the very driver that is enabling 
> > interrupts! You dont get a trace - you get a stack dump of the very place 
> > that is buggy. It does not get any better than that.
> 
> I'm not going to argue.
> 
> Nevertheless, IMO something like the patch below should be sufficient to catch
> these bugs.
> 
> Thanks,
> Rafael
> 
> 
> ---
>  drivers/base/power/main.c |   12 ++++++++++++
>  drivers/base/sys.c        |   21 ++++++++++++++++-----
>  include/linux/pm.h        |   18 ++++++++++++++++++
>  3 files changed, 46 insertions(+), 5 deletions(-)

hm, so now you sprinkle debug checks all around the code, instead of 
putting in a single pair of:

    force_irqs_off_start();
    ...
    force_irqs_off_end();

which would catch everything that your checks would catch - and it would 
catch more. In what way is your approach better?

	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/