[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


 


Rackspace

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