[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |