[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m13b40wnrb.fsf@ebiederm.dsl.xmission.com>
Date: Mon, 19 Mar 2007 22:19:04 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: David Miller <davem@...emloft.net>
Cc: torvalds@...ux-foundation.org, ak@...e.de,
virtualization@...ts.linux-foundation.org, jbeulich@...ell.com,
jeremy@...p.org, xen-devel@...ts.xensource.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
chrisw@...s-sol.org, virtualization@...ts.osdl.org,
anthony@...emonkey.ws, akpm@...ux-foundation.org, mingo@...e.hu
Subject: Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
David Miller <davem@...emloft.net> writes:
> From: Linus Torvalds <torvalds@...ux-foundation.org>
> Date: Mon, 19 Mar 2007 20:18:14 -0700 (PDT)
>
>> > > Please don't subject us to another couple months of hair-pulling only
>> > > to have Linus yank the thing out again, there are certainly more
>> > > useful things to spend time on :-)
>>
>> Good call. Dwarf2 unwinding simply isn't worth doing. But I won't yank it
>> out, I simply won't merge it. It was more than just totally buggy code, it
>> was an inability of the people to understand that even bugfree code
>> isn't enough - you have to be able to also handle buggy data.
>
> Thank you.
Hmm..
I know the feeling I have had a similar rant about the kexec on panic
code path. The code is still no where near as paranoid about normal
kernel things not working as it could be, but by ranting about it
periodically the people doing the work are gradually making it better.
I'm conflicted about the dwarf unwinder. I was off doing other things
at the time so I missed the pain, but I do have a distinct recollection of
the back traces on x86_64 being distinctly worse the on i386. Lately
I haven't seen that so it may be I was misinterpreting what I was
seeing, and the compiler optimizations were what gave me such weird
back traces.
But if the quality of our backtraces has gone down and dwarf unwinder
could give us better back traces it is likely worth pursuing. Of
course it would need to start with the assumption that it's tables
may be borked (the kernel is busted after all) and be much more
careful than Andi's last attempt.
Eric
-
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