Re: [Xen-devel] RE: Memory sharing, is it possible a page is freed in DomU on its way to be shared?

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 04:15 +0100 on 20 Apr (1303272954), Jui-Hao Chiang wrote:
> Hi,
> 
> I remember Tim said there already exist potential problem in p2m type,
> and could be taken care of after 4.1 is released.
> Forget about mem_sharing first, say if I want to grab a page that no
> other Xen code can touch and use, how do I do it in the current Xen?

You take a typed reference, using get_page_and_type().  That's what the
current mem sharing code does, IIRC.  

Fixing the refcounting in the p2m code keeps getting pushed out by other
things, I'm afraid. :(  I hope to look at the general layout of p2m and the
locking today and tomorrow, buyt then I'm away again for the next
while. 

Tim.

> I guess this should not be a problem only for mem_sharing.
> 
> The other solution I am thinking is to use the RCU write lock in
> mem_sharing can solve the race condition on p2m type.
> But it seems the RCU mechanism favors the reader but not the writer,
> in our case, the mem_sharing code.
> If that's the case, then the mem_sharing operation will block for a
> long period, e.g. the guest page fault triggers unshare(), and degrade
> the response time of guest domain.
> 
> Bests,
> Jui-Hao
> 
> On Tue, Apr 19, 2011 at 10:46 PM, pengfei zhang <zpfalpc23@xxxxxxxxxxx> wrote:
> >
> > After thinking of this problem for some time, I think this situation can 
> > not happen for my point of view.
> > After the block disk driver has get the request from I/O dispatcher, if the 
> > buffer memory is freed for other use,
> > no one will notify the driver about this, and this will cause data 
> > reading conflict. So the kernel must do something(protect the buffer until 
> > response from driver?) to avoid this.
> > ________________________________
> > Date: Tue, 19 Apr 2011 06:27:46 -0700
> > From: [hidden email]
> > To: [hidden email]
> > Subject: Memory sharing, is it possible a page is freed in DomU on its way 
> > to be shared?
> >
> > Hi:
> >
> >       Just come up this question.
> >
> >       Say a process in domU read IO, then blkfront driver will have a new 
> > page prepared to
> > fill the IO data. The blkfront pass the gref to blkback in dom0, later 
> > passed  to blktap, then
> > forward to  tapdisk for physical IO read, in memory sharing, the gref may 
> > be nominate to
> > Xen for page sharing again( say this is sharing step).
> >
> >       My question is, it is possible during the IO data comes back from 
> > tapdisk, the page
> > referred by gerf in domU could be freed? (maybe by process termination, or 
> > blkfront free this page)
> >
> >      And if it is possible, then the page is free in domU, it is also 
> > possible that the page be given
> > back to Xen through ballloon driver, and the P2M will be invaild.  This may 
> > make *sharing step*
> > gfn points to a invalid mfn possible.
> >
> >      So is this possible happen?
> >
> >      thanks.
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > [hidden email]
> > http://lists.xensource.com/xen-devel
> >
> >
> > ________________________________
> > If you reply to this email, your message will be added to the discussion 
> > below:
> > http://xen.1045712.n5.nabble.com/Memory-sharing-is-it-possible-a-page-is-freed-in-DomU-on-its-way-to-be-shared-tp4313262p4313262.html
> > To unsubscribe from Xen, click here.
> > ________________________________
> > View this message in context: RE: Memory sharing, is it possible a page is 
> > freed in DomU on its way to be shared?
> > Sent from the Xen - Dev mailing list archive at Nabble.com.
> >
> > _______________________________________________
> > 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

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel