WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] dom0 pvops crash

To: "Jeremy Fitzhardinge" <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] dom0 pvops crash
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 26 Jan 2010 11:53:57 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Tue, 26 Jan 2010 03:54:20 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B5DF8E5.9040906@xxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C783A22C.7599%keir.fraser@xxxxxxxxxxxxx> <4B5DF8E5.9040906@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Jeremy Fitzhardinge <jeremy@xxxxxxxx> 25.01.10 21:02 >>>
>I'll need to refresh my memory for the precise details, but the basic 
>problem is that there's a path in the pagefault code where the kernel 
>breaks its own locking rules by kmapping a high pte page without holding 
>the pagetable lock.  In the native case this is OK, but it breaks Xen 
>because the pte page can be unpinned at that point, but can race with it 
>being pinned on another CPU.This can fail in several ways, depending on 
>the exact timing: the other CPU's pin could fail because of the writable 
>kmapping, or the writable kmap could fail because the page has since 
>become pinned.
>
>The brute-force fix is to lock the pte page properly, but given that its 
>in the hot part of the pagefault path, and the unlocked access is 
>presumably a performance enhancement, I don't think that will fly.

Are you referring to the pte_offset_map() in gup_pte_range()? If so,
would it really be that unacceptable to put a high-page-and-on-Xen
check in there, returning 0 from the function to force using the slow
path?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel