lkml.org 
[lkml]   [2012]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] Avoid dead lock of console related locks in panic case
    On Fri, 30 Nov 2012 17:11:07 +0000
    Seiji Aguchi <seiji.aguchi@hds.com> wrote:

    > If one cpu ,which is taking a logbuf_lock or console_sem,
    > receive IPI/NMI from a panicked cpu via smp_send_stop(),
    > the panicked cpu hangs up in subsequent kmsg_dump()/printk()
    > because logbuf_lock and console_sem are taken in the function calls.
    >
    > This causes a console blank and users can't see panic messages.
    >
    > [Solution]
    >
    > this patch introduces a logic initializing logbuf_lock and console_sem
    > just after smp_send_stop() to avoid dead locks above.

    That is one nasty looking patch :(

    - Makes the logic in this area even more twisty and complex, when
    what we need to do is to simplify it

    - Reinitialises in-use locks

    - Gives the boolean variable "yes" three states, but didn't rename
    that variable to something appropriate.

    - Passes yes==2 into s390's unsuspecting bust_spinlocks() implementation.


    Let's step back a bit. Please identify with great specificity the code
    sites which are stopping other CPUs before taking locks which those
    other CPUs might have been holding.

    Then let's see what we can do to fix up the callers, instead of trying
    to tidy up after they have made this mess.



    \
     
     \ /
      Last update: 2012-11-30 23:41    [W:2.600 / U:0.376 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site