> What I actually meant was: can "this" CPU avoid stopping other CPUs so early?
> If we stop the other CPUs when this CPU is ready to
> stop itself then there will never be such deadlocks.
Let me explain my opinion.
When we focus on the deadlock only, the code will be simple by moving
smp_sen
On Fri, 30 Nov 2012 22:59:13 +
Seiji Aguchi wrote:
> >
> > 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
Thank you for giving me the comment.
> - 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.
On Fri, 30 Nov 2012 17:11:07 +
Seiji Aguchi 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 func
4 matches
Mail list logo
