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: Andi Kleen <ak@xxxxxxx>
Subject: [Xen-devel] Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable
From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 20 Mar 2007 09:52:42 -0700 (PDT)
Cc: jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, mingo@xxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, jbeulich@xxxxxxxxxx, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, chrisw@xxxxxxxxxxxx, virtualization@xxxxxxxxxxxxxx, "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>, anthony@xxxxxxxxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, David Miller <davem@xxxxxxxxxxxxx>
Delivery-date: Wed, 21 Mar 2007 02:24:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070320174159.GA4286@xxxxxxxxxxxxxx>
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.120854.30182994.davem@xxxxxxxxxxxxx> <20070319.204712.118947830.davem@xxxxxxxxxxxxx> <m13b40wnrb.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx> <200703201428.50564.ak@xxxxxxx> <m1ircvswzz.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx> <20070320174159.GA4286@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On Tue, 20 Mar 2007, Andi Kleen wrote:
> No, me and Jan fixed all reported bugs as far as I know.

No you did not. You didn't fix the ones I reported. Which is why it got 
removed, and will not get added back until there is another maintainer.

The ones I reported were all about trusting the stack contents implicitly, 
and assuming that the unwind info was there and valid. Using things like 
"__get_user()" didn't fix it, because if a WARN_ON() happened while we 
held the mm semaphore and the unwind info was bogus, it would take a 
page-fault and deadlock.

Those kinds of things are not acceptable for debugging output. If I cannot 
use WARN_ON() because I hold the MM lock and I'm afraid there might be 
kernel corruption, then something is *wrong*!

And I told you guys this. Over *months*. And you ignored me. You told me 
everything was fine. Each time, somebody else ended up reporting a hang 
where the unwinder was at fault. And since I couldn't trust the 
maintainers to fix it, removing the broken feature that only caused more 
problems than it fixed was the only option.

And you clearly *still* haven't accepted the fact that the code was buggy. 

Does anybody wonder why I wouldn't merge it back?


Xen-devel mailing list

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