Re: [PATCH] Avoid dead lock of console related locks in panic case

[Andrew Morton <akpm@linux-foundation.org>]

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.