From: Andrew Morton <akpm@linux-foundation.org>
To: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"joe@perches.com" <joe@perches.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"kay@vrfy.org" <kay@vrfy.org>,
"jim.cromie@gmail.com" <jim.cromie@gmail.com>,
"mingo@elte.hu" <mingo@elte.hu>,
"sboyd@codeaurora.org" <sboyd@codeaurora.org>,
"jason.wessel@windriver.com" <jason.wessel@windriver.com>,
"a.p.zijlstra@chello.nl" <a.p.zijlstra@chello.nl>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"dle-develop@lists.sourceforge.net"
<dle-develop@lists.sourceforge.net>,
Satoru Moriya <satoru.moriya@hds.com>
Subject: Re: [PATCH] Avoid dead lock of console related locks in panic case
Date: Fri, 30 Nov 2012 15:21:49 -0800 [thread overview]
Message-ID: <20121130152149.6f266216.akpm@linux-foundation.org> (raw)
In-Reply-To: <A5ED84D3BB3A384992CBB9C77DEDA4D414A0339D@USINDEM103.corp.hds.com>
On Fri, 30 Nov 2012 22:59:13 +0000
Seiji Aguchi <seiji.aguchi@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.
next prev parent reply other threads:[~2012-11-30 23:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 17:11 [PATCH] Avoid dead lock of console related locks in panic case Seiji Aguchi
2012-11-30 22:30 ` Andrew Morton
2012-11-30 22:59 ` Seiji Aguchi
2012-11-30 23:21 ` Andrew Morton [this message]
2012-12-01 1:04 ` Seiji Aguchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121130152149.6f266216.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=a.p.zijlstra@chello.nl \
--cc=dle-develop@lists.sourceforge.net \
--cc=gregkh@linuxfoundation.org \
--cc=jason.wessel@windriver.com \
--cc=jim.cromie@gmail.com \
--cc=joe@perches.com \
--cc=kay@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=satoru.moriya@hds.com \
--cc=sboyd@codeaurora.org \
--cc=seiji.aguchi@hds.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox