[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Avoid premature update of M2P in set_typed_p2m_entry
B41;297;0cAt 08:55 +0100 on 06 Jun (1402041318), Jan Beulich wrote: > >>> On 06.06.14 at 00:55, <mukesh.rathor@xxxxxxxxxx> wrote: > > @@ -832,6 +827,11 @@ static int set_typed_p2m_entry(struct domain *d, > > unsigned long gfn, mfn_t mfn, > > gdprintk(XENLOG_ERR, > > "p2m_set_entry failed! mfn=%08lx rc:%d\n", > > mfn_x(get_gfn_query_unlocked(p2m->domain, gfn, &ot)), rc); > > + else if ( p2m_is_ram(ot) ) > > + { > > + ASSERT(mfn_valid(omfn)); > > + set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY); > > + } > > The only possible concern here is that all other code paths in p2m.c > do the M2P updates under lock. Tim - is that a requirement (formally > the M2P isn't really considered serialized by P2M locking I think)? Yet > then again, even if it isn't, the placement here might sooner or later > result in a Coverity warning (recognizing that all other paths do the > update with a lock held)... No, the m2p isn't covered by the p2m lock, but it might be as well to do so in this case anyway, to avoid worrying about race conditions between two invocations of this code. Tim. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |