From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1W18-0000Vb-IL for qemu-devel@nongnu.org; Wed, 15 Aug 2012 01:19:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T1W17-0003VJ-Gw for qemu-devel@nongnu.org; Wed, 15 Aug 2012 01:19:42 -0400 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:39463) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T1W16-0003VB-TD for qemu-devel@nongnu.org; Wed, 15 Aug 2012 01:19:41 -0400 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 15 Aug 2012 10:49:37 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7F5JYuU32112672 for ; Wed, 15 Aug 2012 10:49:34 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q7F5JYgU028356 for ; Wed, 15 Aug 2012 15:19:34 +1000 Date: Wed, 15 Aug 2012 10:51:03 +0530 From: Bharata B Rao Message-ID: <20120815052103.GJ24944@in.ibm.com> References: <20120809130010.GA7960@in.ibm.com> <20120809130216.GC7960@in.ibm.com> <5028F815.40309@redhat.com> <20120814043801.GB24944@in.ibm.com> <502A0C66.3060107@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <502A0C66.3060107@redhat.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: Kevin Wolf Cc: Anthony Liguori , Anand Avati , Stefan Hajnoczi , Vijay Bellur , Amar Tumballi , qemu-devel@nongnu.org, Blue Swirl , Paolo Bonzini On Tue, Aug 14, 2012 at 10:29:26AM +0200, Kevin Wolf wrote: > >>> +static void gluster_finish_aiocb(struct glfs_fd *fd, ssize_t ret, void *arg) > >>> +{ > >>> + GlusterAIOCB *acb = (GlusterAIOCB *)arg; > >>> + BDRVGlusterState *s = acb->common.bs->opaque; > >>> + > >>> + acb->ret = ret; > >>> + if (qemu_gluster_send_pipe(s, acb) < 0) { > >>> + /* > >>> + * Gluster AIO callback thread failed to notify the waiting > >>> + * QEMU thread about IO completion. Nothing much can be done > >>> + * here but to abruptly abort. > >>> + * > >>> + * FIXME: Check if the read side of the fd handler can somehow > >>> + * be notified of this failure paving the way for a graceful exit. > >>> + */ > >>> + error_report("Gluster failed to notify QEMU about IO completion"); > >>> + abort(); > >> > >> In the extreme case you may choose to make this disk inaccessible > >> (something like bs->drv = NULL), but abort() kills the whole VM and > >> should only be called when there is a bug. > > > > There have been concerns raised about this earlier too. I settled for this > > since I couldn't see a better way out and I could see the precedence > > for this in posix-aio-compat.c > > > > So I could just do the necessary cleanup, set bs->drv to NULL and return from > > here ? But how do I wake up the QEMU thread that is waiting on the read side > > of the pipe ? W/o that, the QEMU thread that waits on the read side of the > > pipe is still hung. > > There is no other thread. But you're right, you should probably > unregister the aio_fd_handler and any other pending callbacks. As I clarified in the other mail, this (gluster_finish_aiocb) is called from gluster thread context and hence QEMU thread that raised the original read/write request is still blocked on qemu_aio_wait(). I tried the following cleanup instead of abrupt abort: close(read_fd); /* This will wake up the QEMU thread blocked on select(read_fd...) */ close(write_fd); qemu_aio_set_fd_handler(read_fd, NULL, NULL, NULL, NULL); qemu_aio_release(acb); s->qemu_aio_count--; bs->drv = NULL; I tested this by manually injecting faults into qemu_gluster_send_pipe(). With the above cleanup, the guest kernel crashes with IO errors. Is there anything else that I need to do or do differently to retain the VM running w/o disk access ? I thought of completing the aio callback by doing acb->common.cb(acb->common.opaque, -EIO); but that would do a coroutine enter from gluster thread, which I don't think should be done. Regards, Bharata.