Re: [Xen-devel] [PATCH v2 2/2] xen/m2p: use GNTTABOP_unmap_and_replace to reinstate the original mapping

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2013-07-23 at 09:57 -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Jul 22, 2013 at 06:02:45PM +0100, David Vrabel wrote:
> > On 22/07/13 17:28, Stefano Stabellini wrote:
> > > GNTTABOP_unmap_grant_ref unmaps a grant and replaces it with a 0
> > > mapping instead of reinstating the original mapping.
> > > Doing so separately would be racy.
> > > 
> > > To unmap a grant and reinstate the original mapping atomically we use
> > > GNTTABOP_unmap_and_replace.
> > > GNTTABOP_unmap_and_replace doesn't work with GNTMAP_contains_pte, so
> > > don't use it for kmaps.  GNTTABOP_unmap_and_replace zeroes the mapping
> > > passed in new_addr so we have to reinstate it, however that is a
> > > per-cpu mapping only used for balloon trade pages, so we can be sure that
> > > it's not going to be accessed while the mapping is not valid.
> > 
> > This solves the problem of userspace accessing a disk image on an NFS
> > mount but what would blkback talking to an iSCSI LUN?  Will that need
> > similar fixes to blkback?  This series does not need to fix this now though.
> 
> I am not sure I follow. The blkback using iSCSI LUNs works just fine
> (I am using that - I have LVs of guests on an iSCSI disk).

It is very rare but if you get a TCP retransmit on the iSCSI stream then
it is possible to get the same race with an ACK turning up and
completing the I/O while the transmit is still pending. I'm pretty sure
there have been reports of this in the past,but I can also easily
believe you aren't seeing it, you'd need a heavily stressed and/or
flakey network and a big dollop of bad luck...

Ian.


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