On Fri, 30 Nov 2012 22:59:13 +0000 Seiji Aguchi <seiji.agu...@hds.com> 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 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/
