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: Mon, 26 Jan 2015 15:00:10 +0000
Message-ID: <54C6567A.1000302@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>	<54C260BA.7060506@citrix.com>
	<54C26D00.8000306@citrix.com> <54C2702B.4050508@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.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1YFl9q-0005Vx-6U
	for xen-devel@lists.xenproject.org; Mon, 26 Jan 2015 15:00:54 +0000
In-Reply-To: <54C2702B.4050508@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: David Vrabel <david.vrabel@citrix.com>, =?windows-1252?Q?Roger_Pau_?= =?windows-1252?Q?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 16:00, David Vrabel wrote:
> On 23/01/15 15:47, Roger Pau Monn=E9 wrote:
>> El 23/01/15 a les 15.54, David Vrabel ha escrit:
>>> On 23/01/15 14:31, Roger Pau Monn=E9 wrote:
>>>> El 19/01/15 a les 16.51, David Vrabel ha escrit:
>>>>> +		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 should be fixed to at least be (which is still not fully correct,
>> but it's better):
>>
>> pages +=3D invcount;
>> num -=3D invcount;
>>
>> I hope an example will clarify this, suppose we have the following pages
>> array:
>>
>> pages[0] =3D persistent grant
>> pages[1] =3D persistent grant
>> pages[2] =3D regular grant
>> pages[3] =3D persistent grant
>> pages[4] =3D regular grant
>>
>> And batch is 1. In this case, the unmapped grant will be pages[2], but
>> then due to the code below pages will be updated to point to &pages[1],
>> which has already been scanned. If this was done correctly pages should
>> point to &pages[3]. As said, it's not really a bug, but the loop is
>> sub-optimal.
> =

> Ah ha.  Thanks for the clear explanation.
> =

> gnttab_blkback_unmap_prepare() stops once its been through the whole
> batch regardless of whether it filled the array with ops so we don't
> check a page twice but this does mean we have a sub-optimal number of ops.

This is not a hot path (it's only called during error recovery).  Are
you happy to leave this as is?

David