This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravi

To: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
From: Andi Kleen <ak@xxxxxxx>
Date: Tue, 20 Mar 2007 21:23:52 +0100
Cc: jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, mingo@xxxxxxx, Andi Kleen <ak@xxxxxxx>, jbeulich@xxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, chrisw@xxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxx, "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>, anthony@xxxxxxxxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, David Miller <davem@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx
Delivery-date: Tue, 20 Mar 2007 12:24:11 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.64.0703201145570.6730@xxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20070319.204712.118947830.davem@xxxxxxxxxxxxx> <m13b40wnrb.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx> <200703201428.50564.ak@xxxxxxx> <m1ircvswzz.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx> <20070320174159.GA4286@xxxxxxxxxxxxxx> <Pine.LNX.4.64.0703200947501.6730@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20070320180359.GB4286@xxxxxxxxxxxxxx> <Pine.LNX.4.64.0703201022040.6730@xxxxxxxxxxxxxxxxxxxxxxxxxx> <20070320192118.GD4286@xxxxxxxxxxxxxx> <Pine.LNX.4.64.0703201145570.6730@xxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, Mar 20, 2007 at 11:49:39AM -0700, Linus Torvalds wrote:
> On Tue, 20 Mar 2007, Andi Kleen wrote:
> > 
> > So what is your proposed alternative to handle long backtraces? 
> > You didn't answer that question. Please do, I'm curious about your thoughts
> > in this area.
> the thing is, I'd rather see a long backtrace that is hard to decipher but 
> that *never* *ever* causes any additional problems, over a pretty one.

Well it causes additional problems. We had some cases where it was really
hard to distingush garbage and the true call chain. I can probably dig
out some examples if you want.

With lots of call backs (e.g. common with sysfs) it is also frequently
not obvious how the call chains are supposed to go.

I would have agreed with you in the 2.4 time frame. It was also
always fun to explain this to a newbie with oopses and watch their
face when they secretly think you're crazy ;-) But code is getting
much and more complex unfortunately and I had a few cases where
it was really ugly to sort them out. 

> Because that's really the issue: do you want a "pretty" backtrace, or do 
> you want one that is rock solid but has some crud in it.

I just want an as exact backtrace as possible. I also think
that we can make the unwinder robust enough.

> I'll take the rock solid one any day. Especially as even the pretty one 
> won't fix the most common problem, which is "I don't see the caller" (due 
> to inlining or tail-calls).

The problem is not one or a few levels of calls. That can be always figured
out from the source. The problem is when you have a double
digit number of them with non obvious (dynamic indirect) dependencies.  Yes it 
can be figured out too, but it is a long and very annoying process
with lots of grepping etc. and even then you sometimes can't be 100% 
sure in some cases. 

It's also a mechanic process that just cries to be done by a machine instead.

> In contrast, the ugly backtrace will have some "garbage entries" from 
> previous frames that didn't get overwritten, but there have actually been 

If it was only a few that would be great ...


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>