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:	Fri, 10 Feb 2012 17:27:14 -0200
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Jiri Olsa <jolsa@...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

Em Fri, Feb 10, 2012 at 10:59:51AM -0800, Linus Torvalds escreveu:
> 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.

"Vote for --fno-omit-frame-pointer! One register is a cheap price to pay
for not going insane!"

/me goes back to non political things.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ