This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Problem with PV disk and iSCSI

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Problem with PV disk and iSCSI
From: Gary Grebus <ggrebus@xxxxxxxxxxxxxxx>
Date: Mon, 11 Feb 2008 10:26:27 -0500
Cc: Kurt Hackel <kurt.hackel@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 11 Feb 2008 07:27:01 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3D30FC6.1387F%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C3D30FC6.1387F%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Sat, 2008-02-09 at 08:07 +0000, Keir Fraser wrote:
> On 9/2/08 06:15, "Kurt Hackel" <kurt.hackel@xxxxxxxxxx> wrote:
> >> I'm thinking blkback will have to make a dom0 copy of the page before
> >> doing the unmap if there are still extra references?
> > 
> > Can the unmap be deferred, handled by the last reference holder?  Or
> > does this open up a potential security hole?
> netback already does this kind of reference counting. It oughtn't to be hard
> to check the page reference count in the blkback I/O completion handler and,
> if non-zero, set up a callback for when the count does fall to zero. And
> defer responding to the frontend until that time. Netback is even more
> sophisticated in that it also sets a time out and if the page languishes for
> too long with non-zero count, it's able to forcibly copy-and-release the
> page. I don't think we need to go that far for blkback however.

In the failure I'm seeing, the skb could sit on a socket queue
indefinitely.  The application reading the socket could be blocked for
some other reason.  blkback can't defer responding to blkfront
(completing the guest I/O).

I think blkback needs to assume that a completion with a non-zero page
reference count means it needs to make a copy, or implement a timeout
like netback.


Gary Grebus
Virtual Iron Software, Inc.

Xen-devel mailing list