linux-kernel - Re: [RFC 0/5] kernel: backtrace unwind support

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]

Message-ID: <CA+55aFxgPXjGh0GSHaUGm6-Pfdjjk=PAP7HMuZHcFGE92VutUQ@mail.gmail.com>
Date:	Fri, 10 Feb 2012 10:59:51 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Jiri Olsa <jolsa@...hat.com>, acme@...hat.com, mingo@...e.hu,
	paulus@...ba.org, cjashfor@...ux.vnet.ibm.com, fweisbec@...il.com,
	linux-kernel@...r.kernel.org,
	"James E.J. Bottomley" <jejb@...isc-linux.org>,
	Jan Blunck <jblunck@...e.de>
Subject: Re: [RFC 0/5] kernel: backtrace unwind support

On Fri, Feb 10, 2012 at 9:43 AM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
>
> So I CC'ed Linus who has a strong here, jejb since he's the one that
> told me several time there's a number of literate dwarfs already in the
> kernel and Jan because I think it was him that tried last on x86.

I never *ever* want to see this code ever again.

Sorry, but last time was too f*cking painful. The whole (and *only*)
point of unwinders is to make debugging easy when a bug occurs. But
the f*cking dwarf unwinder had bugs itself, or our dwarf information
had bugs, and in either case it actually turned several "trivial" bugs
into a total undebuggable hell.

It was made doubly painful by the developers involved then several
times ignoring the problem, and claiming the code was bug-free when it
clearly wasn't, or trying to claim that the problem was that we set up
some random dwarf information wrong, when THAT GOES WITHOUT SAYING
(since dwarf is a complex mess that never gets any actual testing
except when things go wrong - at which point the code had better work
regardless of whether the dwarf info was correct or not).

So no. An unwinder that is several hundred lines long is simply not
even *remotely* interesting to me.

If you can mathematically prove that the unwinder is correct - even in
the presence of bogus and actively incorrect unwinding information -
and never ever follows a bad pointer, I'll reconsider.

In the absence of that, just follow the damn chain on the stack
*without* the "smarts" of an inevitably buggy piece of crap.

                    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/