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

From: Andrew Morton
Date: Fri Nov 30 2012 - 18:21:40 EST


On Fri, 30 Nov 2012 22:59:13 +0000
Seiji Aguchi <seiji.aguchi@xxxxxxx> 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 the callers, instead of trying to tidy up after they have made this mess.
>
> OK.
> I will update my patch without adding complexity.
> The logic will be as follows, if I understand your comment correctly.
>
> - take console related locks (logbuf_lock, console_sem)
> - stop other cpus
> - release those locks

That would be one way around the problem. It's still a bit messy,
because we'll have to take more and more locks in the future, as we
identify them.

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/