From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Vrabel <david.vrabel@citrix.com>
Subject: Re: [PATCH 12/14] xen-blkback: safely unmap grants in
 case they are still in use
Date: Fri, 23 Jan 2015 14:54:50 +0000
Message-ID: <54C260BA.7060506@citrix.com>
References: <1421682692-20628-1-git-send-email-david.vrabel@citrix.com>
	<1421682692-20628-13-git-send-email-david.vrabel@citrix.com>
	<54C25B2F.9090205@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1YEfdP-0004LH-85
	for xen-devel@lists.xenproject.org; Fri, 23 Jan 2015 14:54:55 +0000
In-Reply-To: <54C25B2F.9090205@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: =?windows-1252?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com>, xen-devel@lists.xenproject.org
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>, Jenny Herbert <jennifer.herbert@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 23/01/15 14:31, Roger Pau Monn=E9 wrote:
> El 19/01/15 a les 16.51, David Vrabel ha escrit:
>> From: Jenny Herbert <jennifer.herbert@citrix.com>
>>
>> +static void xen_blkbk_unmap(struct xen_blkif *blkif,
>> +                            struct grant_page *pages[],
>> +                            int num)
>> +{
>> +	struct gnttab_unmap_grant_ref unmap[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> +	struct page *unmap_pages[BLKIF_MAX_SEGMENTS_PER_REQUEST];
>> +	unsigned int invcount =3D 0;
>> +	int ret;
>> +
>> +	while (num) {
>> +		unsigned int batch =3D min(num, BLKIF_MAX_SEGMENTS_PER_REQUEST);
>> +		=

>> +		invcount =3D xen_blkbk_unmap_prepare(blkif, pages, batch,
>> +						   unmap, unmap_pages);
> =

> I would add:
> =

> BUG_ON(invcount !=3D batch);

I'm confused.  Surely invcount < batch is valid if one or more pages
within this batch are persistently mapped?

>> +		if (invcount) {
>> +			ret =3D gnttab_unmap_refs(unmap, NULL, unmap_pages, invcount);
>>  			BUG_ON(ret);
>> -			put_free_pages(blkif, unmap_pages, invcount);
>> -			invcount =3D 0;
>> +			xen_blkbk_unmap_done(blkif, unmap_pages, invcount);
>>  		}
>> -	}
>> -	if (invcount) {
>> -		ret =3D gnttab_unmap_refs(unmap, NULL, unmap_pages, invcount);
>> -		BUG_ON(ret);
>> -		put_free_pages(blkif, unmap_pages, invcount);
>> +		pages +=3D batch;
>> +		num -=3D batch;
> =

> This loop is sort of buggy, it should work, but it is sub-optimal.
> =

> The pages array can contain both persistent grants and normal grants
> (the ones that we should unmap). So blindly increasing the pages pointer
> with batch will mean that we could be iterating over grants that have
> already been freed. It is not really an issue because we set handle to
> BLKBACK_INVALID_HANDLE, but it's a waste.

Again, I don't follow you here.

David