lkml.org 
[lkml]   [2009]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Linux 2.6.29-rc2] BUG: using smp_processor_id() in preemptible
Date
On Thursday 29 January 2009, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> > On Tuesday 27 January 2009, Ingo Molnar wrote:
> > >
> > > * Rafael J. Wysocki <rjw@sisk.pl> 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();

And what debug options exactly would that require to be set to work?

> which would catch everything that your checks would catch - and it would
> catch more.

Except that the checks trigger in specific places, so if a check triggers you
know precisely where the bug happened regardless of what garbage is in the call
trace.

> In what way is your approach better?

That depends on the answer to my question above.

Thanks,
Rafael


\
 
 \ /
  Last update: 2009-01-29 23:49    [from the cache]
©2003-2011 Jasper Spaans