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    [W:0.058 / U:332.200 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site