From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:56601)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1TNlvu-0001tU-KI
	for qemu-devel@nongnu.org; Mon, 15 Oct 2012 10:46:22 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1TNlvp-0002EL-Of
	for qemu-devel@nongnu.org; Mon, 15 Oct 2012 10:46:18 -0400
Message-ID: <507C21AE.7070307@redhat.com>
Date: Mon, 15 Oct 2012 16:46:06 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <20120513160331.5b774c93.yizhouzhou@ict.ac.cn>
	<4FB0F89F.6080306@redhat.com> <4FD74513.2000500@suse.de>
	<4FD747BF.3020809@redhat.com> <50783CCA.902@suse.de>
	<507BD3D1.3010804@redhat.com> <507C1D95.9030402@suse.de>
In-Reply-To: <507C1D95.9030402@suse.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] fixing qemu-0.1X endless loop in
	qcow2_alloc_cluster_offset
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?ISO-8859-1?Q?Andreas_F=E4rber?= <afaerber@suse.de>
Cc: qemu-devel@nongnu.org, qemu-stable@nongnu.org, Michael Tokarev <mjt@tls.msk.ru>, Zhouyi Zhou <yizhouzhou@ict.ac.cn>, Bruce Rogers <brogers@suse.com>

Am 15.10.2012 16:28, schrieb Andreas F=E4rber:
>> What I'm suggesting (not even compile tested!) is:
>>
>> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
>>
>> diff --git a/block/qcow2.c b/block/qcow2.c
>> index 48e1b95..d665675 100644
>> --- a/block/qcow2.c
>> +++ b/block/qcow2.c
>> @@ -388,10 +388,7 @@ typedef struct QCowAIOCB {
>>
>>  static void qcow2_aio_cancel(BlockDriverAIOCB *blockacb)
>>  {
>> -    QCowAIOCB *acb =3D container_of(blockacb, QCowAIOCB, common);
>> -    if (acb->hd_aiocb)
>> -        bdrv_aio_cancel(acb->hd_aiocb);
>> -    qemu_aio_release(acb);
>> +    qemu_aio_flush();
>>  }
>>
>>  static AIOPool qcow2_aio_pool =3D {
>=20
> Compiles fine. Is there a particular test case to invoke this code path=
?

As far as I know, the common way to get this were IDE resets. However,
I'm not sure what you need to do with a Linux guest if you want it to
reset the IDE controller...

> Does this attempt to fix the cluster leaks you mentioned as well, or
> just the cluster allocation endless loop?

Instead of cancelling the in-flight requests it waits for their
completion, so in the end we should be in an consistent state without
cluster leaks.

Kevin