From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41587) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9CR4-0003LW-1Q for qemu-devel@nongnu.org; Wed, 05 Sep 2012 06:02:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9CQz-0002mj-Og for qemu-devel@nongnu.org; Wed, 05 Sep 2012 06:02:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9CQz-0002mc-Gl for qemu-devel@nongnu.org; Wed, 05 Sep 2012 06:02:09 -0400 Message-ID: <50472316.4060106@redhat.com> Date: Wed, 05 Sep 2012 12:01:58 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <20120809130010.GA7960@in.ibm.com> <20120809130216.GC7960@in.ibm.com> <20120905074106.GA28080@in.ibm.com> In-Reply-To: <20120905074106.GA28080@in.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU block backend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: bharata@linux.vnet.ibm.com Cc: Anthony Liguori , Anand Avati , Stefan Hajnoczi , Vijay Bellur , Amar Tumballi , qemu-devel@nongnu.org, Blue Swirl , Paolo Bonzini Am 05.09.2012 09:41, schrieb Bharata B Rao: > 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. Right. .cb is set by qemu_gluster_aio_rw/flush(), and the only way these can be called is through bdrv_co_io_em() and bdrv_co_flush(), which both set bdrv_co_io_em_complete as the callback. > 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. Why? A coroutine that yields before it's completed must be reentered, no matter whether it's been created for a single request or if it already existed. Conversely, a coroutine that you enter, always yields at some point and then you return from the qemu_coroutine_enter() and get back to this line of code. If you never come back to this point, there's a bug somewhere. > 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 ? > > Creating qcow2 image would lead to this scenario where > ->bdrv_create (=qcow2_create) will create a coroutine and subsequently > read and write are called within qcow2_create in coroutine context itself. Can you describe in more detail what code paths it's taking and at which point you're thinking it's wrong? Kevin