Mailing List Archive

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: ml-node+4313262-1641811680-197056@n5.nabble.com
To: zpfalpc23@hotmail.com
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: http://xen.1045712.n5.nabble.com/Memory-sharing-is-it-possible-a-page-is-freed-in-DomU-on-its-way-to-be-shared-tp4313262p4313461.html
Sent from the Xen - Dev mailing list archive at Nabble.com.

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?
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@hotmail.com> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

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

At 14:26 +0100 on 19 Apr (1303223214), MaoXiaoyun wrote:
> 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?

It shouldn't be. The reference counting of pages means that if the mem
sharing code has taken a reference to the page it can't be freed until
it gives it up again. Do you think you've seen this happening?

Tim.

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

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

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@hotmail.com> 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@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

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

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