Re: [Xen-devel] get_gfn_query() locking

[Tim Deegan <tim@xxxxxxx>]

At 09:23 +0000 on 30 Oct (1351588996), Jan Beulich wrote:
> while looking at how "X86/vMCE: handle broken page occurred
> before migration" uses the p2m code, I wondered whether the
> comment
> 
>  * N.B. get_gfn_query() is the _only_ one guaranteed not to take the
>  * p2m lock; none of the others can be called with the p2m or paging
>  * lock held. */
> 
> isn't stale 

Yes, it seems to be stale.  I think that even with the originally
proposed fine-grained p2m locking it would have been possible for this
to take the p2m lock. :(

> - afaict with get_gfn_type_access() passing "1" for the
> "locked" parameter of __get_gfn_type_access(), there's no way
> to avoid the locking without using __get_gfn_type_access()
> directly.

get_gfn_query_unlocked() is the way to do lookups without the lock, but
of course if you do that then you've no guarantee that the mfn it
returns won't get freed under your feet.

> And then again, with the p2m lock being recursive these
> days, I don't think there's any harm calling the other methods
> here with that lock held.

True, but it wouldn't be safe to call it with the paging lock held.
OTOH since we're not seeing any crashes from the lock-ordering
constraints maybe we don't do that.

Andres, what do you think?  Can we just drop/amend that comment?

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel