lkml.org 
[lkml]   [2012]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [RFC][PATCH v4 -next 1/4] Move kmsg_dump(KMSG_DUMP_PANIC) below smp_send_stop()
    Date
    > The explanation is great. but In my opinion, I still insist that
    > a WARN_ON() is necessary. What do you think, Tony and Don?

    I disagree - a WARN_ON() would clutter the log with a stack trace of
    dubious usefulness - possibly displacing something earlier in the
    console log from being saved to pstore.

    I'm about 80% sold on the idea of moving the call below smp_send_stop().
    It does make life simpler for pstore (though not completely pain free,
    ignoring locks is safe only in as far as we know that other cpus aren't
    actually trying to modify things - there is still some problem if the
    other cpu had a device or data structure in some special state when
    smp_send_stop() interrupted it). The 20% of me that isn't buying this
    still has worries that smp_send_stop() might fail in one of several ways:
    1) Fails to actually stop one or more other cpus (this is similar to our
    current situation where other cpus may interfere with us saving kmsg in
    pstore).
    2) Causes another fault, thus recursively entering the panic path.
    3) Hangs - causing us to miss saving to pstore.

    I don't know what can be done to resolve this - it is hard to make a
    100% convincing argument about the execution of any code in the panic
    path.

    -Tony
    \
     
     \ /
      Last update: 2012-01-11 23:25    [W:0.021 / U:0.328 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site