From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ9CK-0001ss-GI for qemu-devel@nongnu.org; Tue, 23 Jun 2009 12:50:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ9CF-0001r0-Qt for qemu-devel@nongnu.org; Tue, 23 Jun 2009 12:50:15 -0400 Received: from [199.232.76.173] (port=38476 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ9CF-0001qu-Is for qemu-devel@nongnu.org; Tue, 23 Jun 2009 12:50:11 -0400 Received: from verein.lst.de ([213.95.11.210]:57476) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1MJ9CE-0005SD-Iy for qemu-devel@nongnu.org; Tue, 23 Jun 2009 12:50:11 -0400 Date: Tue, 23 Jun 2009 18:50:06 +0200 From: Christoph Hellwig Subject: Re: [Qemu-devel] [PATCH] block: Clean up after deleting BHs Message-ID: <20090623165006.GC27211@lst.de> References: <1245763236-23464-1-git-send-email-avi@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1245763236-23464-1-git-send-email-avi@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel@nongnu.org On Tue, Jun 23, 2009 at 04:20:36PM +0300, Avi Kivity wrote: > Commit 6a7ad299 ("Call qemu_bh_delete at bdrv_aio_bh_cb") deletes emulated > aio bottom halves to prevent endless accumulation. However, it leaves a > stale ->bh pointer, which is then waited on when the aio is reused. > > Zeroing the pointer fixes the issue, allowing vmdk format images to be used. What operations on vmdk images does this cause to fail? qemu-iotests seems to do fine on vmdk so it's nothing yet exercised by it. > Signed-off-by: Avi Kivity > --- > block.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/block.c b/block.c > index aca5a6d..cefbe77 100644 > --- a/block.c > +++ b/block.c > @@ -1374,6 +1374,7 @@ static void bdrv_aio_cancel_em(BlockDriverAIOCB *blockacb) > { > BlockDriverAIOCBSync *acb = (BlockDriverAIOCBSync *)blockacb; > qemu_bh_delete(acb->bh); > + acb->bh = NULL; > qemu_aio_release(acb); > } > > @@ -1391,6 +1392,7 @@ static void bdrv_aio_bh_cb(void *opaque) > qemu_vfree(acb->bounce); > acb->common.cb(acb->common.opaque, acb->ret); > qemu_bh_delete(acb->bh); > + acb->bh = NULL; > qemu_aio_release(acb); > } I think not having the state of the private acb area cleared over a free/realloc cycle is pretty dangerous. Wouldn't it be better to always clear that space in qemu_aio_get?