linux-kernel - Re: boot failure, "DWARF2 unwinder stuck at 0xc0100199"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Aug 2006 10:01:36 +0200
From:	Andi Kleen <ak@...e.de>
To:	Andrew Morton <akpm@...l.org>
Cc:	"Randy.Dunlap" <rdunlap@...otime.net>,
	"Jan Beulich" <jbeulich@...ell.com>,
	"J. Bruce Fields" <bfields@...ldses.org>,
	linux-kernel@...r.kernel.org
Subject: Re: boot failure, "DWARF2 unwinder stuck at 0xc0100199"

On Tuesday 22 August 2006 06:20, Andrew Morton wrote:
> On Mon, 21 Aug 2006 09:47:18 -0700
> "Randy.Dunlap" <rdunlap@...otime.net> wrote:
> 
> > > The 'stuck' unwinder issue at hand already has a fix, though planned to
> > > be merged for 2.6.19 only. The crash after switching to the legacy
> > > stack trace code is bad, though, but has little to do with the unwinder
> > > additions/changes. The way that code reads the stack is just
> > > inappropriate in contexts where things must be expected to be broken.
> > 
> > "merged for 2.6.19" meaning:
> > - in (before) 2.6.19, or
> > - after 2.6.19 is released
> > 
> > If "after," then it will likely need to be added to -stable also,
> > so it might as well go in "before" 2.6.19 is released.
> 
> Precisely.
> 
> Guys, this unwinder change has been quite problematic.  We really cannot
> let this badness out into 2.6.18 - it degrades our ability to debug every
> subsystem in the entire kernel.  Would marking it CONFIG_BROKEN get us back 
> to 2.6.17 behaviour?

IMHO just some stucks is tolerable for .18 and .18-stable, as long as it doesn't 
add new crashes and the fallback always gives an useful backtrace (that is why I 
added the fallback -- to make sure no information is lost) 

Short term the stucks are a bit ugly but I hope with .19 or .20 longer 
term we will have much better backtraces without false positives
(ok assuming people turn it on). The code queued for .19 should
be already pretty good now (ok after I fixed one nasty problem yesterday
that added some new ones compared to .18)

> 
> Has anyone even tried to reproduce Bruce's crash?

I looked at it a bit, but it puzzles me. The chaining for the interrupt stacks
on i386 -- which is what seems to be corrupted here -- shouldn't have changed at all 
by the unwinder changes.

I suspect it would crash without unwinder too. Bruce, do you get the 
same crash when you boot with "call_trace=old" ? 

-Andi

-
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/