[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0610040809070.3952@g5.osdl.org>
Date: Wed, 4 Oct 2006 08:12:10 -0700 (PDT)
From: Linus Torvalds <torvalds@...l.org>
To: Jan Beulich <jbeulich@...ell.com>
cc: Ingo Molnar <mingo@...e.hu>, Eric Rannaud <eric.rannaud@...il.com>,
Andrew Morton <akpm@...l.org>, Andi Kleen <ak@...e.de>,
Chandra Seetharaman <sekharan@...ibm.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
nagar@...son.ibm.com
Subject: Re: BUG-lockdep and freeze (was: Arrr! Linux 2.6.18)
On Wed, 4 Oct 2006, Jan Beulich wrote:
>
> Again, a corrupt stack will not allow you getting reliable data out of the
> old unwinder either. Even worse when you consider a stack overflow and
> your request for range checks (or pointers into the stack) - you might not
> get a stack trace then at all.
Who cares?
Not getting data out of a corrupt stack isn't the problem.
Getting an OOPS is the problem.
Jan, did you follow the actual thread at all?
This is _not_ about getting "perfect data". This is about a dead machine
that was killed not by the original bug, but by the DEBUGGING CODE it
triggered.
In other words, in this case the debugging code made things harder to
debug. That's bad, bad, bad. That negates the whole point of having
debugging code in the first place.
In contrast, the old x86 (32-bit) stack dumper was damn safe. If the
original %esp was at all a valid pointer (and it had to be, since
otherwise you'd have gotten a double fault!), it would print out something
_without_ crapping all over the machine. Maybe it wouldn't print out
anything nice, but it would never make things WORSE.
See the difference?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists