public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] 2.4.13-pre3 arm/i386/mips/mips64/s390/s390x/sh die() deadlock
Date: Tue, 16 Oct 2001 12:58:21 +1000	[thread overview]
Message-ID: <18966.1003201101@kao2.melbourne.sgi.com> (raw)
In-Reply-To: Your message of "Mon, 15 Oct 2001 19:36:02 MST." <Pine.LNX.4.33.0110151934060.4179-100000@penguin.transmeta.com>

On Mon, 15 Oct 2001 19:36:02 -0700 (PDT), 
Linus Torvalds <torvalds@transmeta.com> wrote:
>On Tue, 16 Oct 2001, Keith Owens wrote:
>>
>> Any die() routine that uses die_lock to avoid multiple cpu reentrancy
>> will deadlock on recursive die() errors.
>
>Well, I have to say that I personally have always considered the "die"
>lock to not be about multiple CPU re-entrancy, but _exactly_ to stop
>infinite oops reports if an oops itself oopses.
>
>I much prefer a dead machine with a partially visible oops over a oops
>where the original oops has scrolled away due to recursive faults.

AFAIK, Andrew Morton was considering concurrent calls to die() when he
added die_lock.  There had been bug reports where both cpus were trying
to dump registers at the same time so the output was interleaved and
unreadable, die_lock prevented that.

IMHO it is unrealistic to expect that all code inside die() will never
fail.  Any unexpected kernel corruption could cause the register or
backtrace dump to fail.  The patch gets the best of both worlds.  It
protects against recursive errors and against concurrent calls to
die().


  reply	other threads:[~2001-10-16  2:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-16  2:23 [patch] 2.4.13-pre3 arm/i386/mips/mips64/s390/s390x/sh die() deadlock Keith Owens
2001-10-16  2:36 ` Linus Torvalds
2001-10-16  2:58   ` Keith Owens [this message]
2001-10-16  4:27     ` Keith Owens
  -- strict thread matches above, loose matches on Subject: below --
2001-10-16  3:35 Strumila, John

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=18966.1003201101@kao2.melbourne.sgi.com \
    --to=kaos@ocs.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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