[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] regression from c/s 22071:c5aed2e049bc (ept: Put locks around ept_get_entry) ?
Yes, I have to apologize: I have a queue of PoD, p2m, and ept-related fixes that I haven't pushed to the list because: * they require non-negligible reworking * it's been really difficult for me to set up an OSS-based system to test them It actually turns out that doing locking in ept_get_entry() is the wrong thing to do anyway; it can cause the following deadlock: p2m_change_type [grabs p2m lock] -> set_p2m_entry -> ept_set_entry -> ept_set_middle_level -> p2m_alloc [grabs hap lock] write cr4 -> hap_update_paging_modes [grabes hap lock] -> hap_update_cr3 -> gfn_to_mfn -> ept_get_entry -> [grabs p2m lock] Attached is a ported patch that removes locking in ept_get_entry(), and implements access-once semantics for reading and writing. This solves the original problem (a race between reading and writing the table) without causing deadlocks. I haven't had a chance to test it -- can you give it a spin? Thanks, -George On Tue, Dec 14, 2010 at 8:39 AM, Jan Beulich <JBeulich@xxxxxxxxxx> wrote: > George, > > with ept_get_entry() calling ept_pod_check_and_populate(), which in > turn unconditionally calls p2m_lock(), we got a report of the BUG() in > p2m_lock() triggering (in a backport of the patch on top of 4.0.1 - the > logic seems unchanged in -unstable, and hence the issue ought to > similarly exist there). Wouldn't therefore ept_pod_check_and_populate(), > only ever called from ept_get_entry(), not need to do any locking on > its own at all? > > Thanks, Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel >
_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
Lists.xenproject.org is hosted with RackSpace, monitoring our