All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: torvalds@osdl.org, linux-kernel <linux-kernel@vger.kernel.org>,
	Jens Axboe <jens.axboe@oracle.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>
Subject: Re: [PATCH] [2/2] Don't complain about disabled irqs when the system has paniced
Date: Tue, 02 Sep 2008 16:45:17 +0200	[thread overview]
Message-ID: <1220366717.8609.65.camel@twins> (raw)
In-Reply-To: <20080902144051.GM18288@one.firstfloor.org>

On Tue, 2008-09-02 at 16:40 +0200, Andi Kleen wrote:
> On Tue, Sep 02, 2008 at 04:28:03PM +0200, Peter Zijlstra wrote:
> > On Tue, 2008-09-02 at 15:49 +0200, Andi Kleen wrote:
> > > panic calls smp_send_stop which eventually calls smp_call_function_*.
> > > smp_call_function warns about disabled interrupts. But it's legal
> > > to call panic in this case. When this happens panic() prints
> > > several ugly backtraces. So don't check for disabled interrupts
> > > in panic state.
> > 
> > While it might be legal for panic to be called from such contexts, I
> > understand those warnings are there to warn of deadlocks.
> > 
> > So with the below patch you allow panic to deadlock if I understand
> > things correctly.
> 
> Please describe the deadlock exactly.  I don't think it can deadlock 
> in this case. 

Then why are those warnings there? The deadlock is for the CSD_FLAG_WAIT
case, which can always happen due to the static csd data fallback.

The deadlock scenario is long the lines of two such smp_call_function*()
both under irq disabled calling each other with CSD_FLAG_WAIT set.
Neither remote cpu will handle the IPI due to irqs being disabled, so
we'll wait at-infinitum for completion.

> Besides do you prefer to not allow panic from interrupts/machine
> checks etc. anymore? 

However did I imply that, I just said your fix looked iffy.


  reply	other threads:[~2008-09-02 14:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-02 13:49 [PATCH] [0/2] Fix panic regression in 2.6.27 Andi Kleen
2008-09-02 13:49 ` [PATCH] [1/2] Add a SYSTEM_PANIC state Andi Kleen
2008-09-03 19:04   ` Andrew Morton
2008-09-03 19:16     ` Andi Kleen
2008-09-03 19:32       ` Andrew Morton
2008-09-03 19:44         ` Andi Kleen
2008-09-02 13:49 ` [PATCH] [2/2] Don't complain about disabled irqs when the system has paniced Andi Kleen
2008-09-02 14:28   ` Peter Zijlstra
2008-09-02 14:40     ` Andi Kleen
2008-09-02 14:45       ` Peter Zijlstra [this message]
2008-09-02 15:00         ` Andi Kleen
2008-09-03  6:02           ` Nick Piggin
2008-09-03  6:59             ` Andi Kleen
2008-09-03  9:37               ` Nick Piggin
2008-09-03  9:48                 ` Andi Kleen
2008-09-03 10:17                   ` Nick Piggin
2008-09-03 10:26                     ` Jens Axboe
2008-09-12 19:50   ` Pavel Machek

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=1220366717.8609.65.camel@twins \
    --to=peterz@infradead.org \
    --cc=andi@firstfloor.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=torvalds@osdl.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.