On Fri, 30 Nov 2012 17:11:07 +0000 Seiji Aguchi <seiji.agu...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
