From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9CKs-0001Z6-MW for qemu-devel@nongnu.org; Wed, 05 Sep 2012 05:55:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9CKn-0000qb-75 for qemu-devel@nongnu.org; Wed, 05 Sep 2012 05:55:50 -0400 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:35337) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9CKk-0000o4-4p for qemu-devel@nongnu.org; Wed, 05 Sep 2012 05:55:44 -0400 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 5 Sep 2012 19:55:08 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q859kOX431522948 for ; Wed, 5 Sep 2012 19:46:25 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q859tVRo017118 for ; Wed, 5 Sep 2012 19:55:31 +1000 Date: Wed, 5 Sep 2012 15:27:16 +0530 From: Bharata B Rao Message-ID: <20120905095431.GB28080@in.ibm.com> References: <20120809130010.GA7960@in.ibm.com> <20120809130216.GC7960@in.ibm.com> <20120905074106.GA28080@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120905074106.GA28080@in.ibm.com> Subject: Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Anthony Liguori , Paolo Bonzini , Kevin Wolf Cc: Blue Swirl , Anand Avati , Amar Tumballi , Stefan Hajnoczi , Vijay Bellur On Wed, Sep 05, 2012 at 01:11:06PM +0530, Bharata B Rao wrote: > On Thu, Aug 09, 2012 at 06:32:16PM +0530, Bharata B Rao wrote: > > +static void qemu_gluster_complete_aio(GlusterAIOCB *acb) > > +{ > > + int ret; > > + > > + if (acb->canceled) { > > + qemu_aio_release(acb); > > + return; > > + } > > + > > + if (acb->ret == acb->size) { > > + ret = 0; /* Success */ > > + } else if (acb->ret < 0) { > > + ret = acb->ret; /* Read/Write failed */ > > + } else { > > + ret = -EIO; /* Partial read/write - fail it */ > > + } > > + acb->common.cb(acb->common.opaque, ret); > > The .cb() here is bdrv_co_io_em_complete(). It does qemu_coroutine_enter(), > handles the return value and comes back here. > > But if the bdrv_read or bdrv_write or bdrv_flush was called from a > coroutine context (as against they themselves creating a new coroutine), > the above .cb() call above doesn't return to this point. Hence I won't > be able to release the acb and decrement the qemu_aio_count. > > What could be the issue here ? In general, how do I ensure that my > aio calls get completed correctly in such scenarios where bdrv_read etc > are called from coroutine context rather than from main thread context ? One way to handle this is not to do completion from gluster thread but instead schedule a BH that does the completion. In fact I had this approach in the earlier versions, but resorted to directly calling completion from gluster thread as I didn't see the value of using a BH for completion. But I guess its indeed needed to support such scenarios (qcow2 image creation on gluster backend). Regards, Bharata.