[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] dom0 pvops crash



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.