From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCWGI-0002lT-Ka for qemu-devel@nongnu.org; Thu, 22 Aug 2013 10:53:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VCWGC-0006BY-Ld for qemu-devel@nongnu.org; Thu, 22 Aug 2013 10:53:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32743) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VCWGC-0006Az-D6 for qemu-devel@nongnu.org; Thu, 22 Aug 2013 10:53:16 -0400 Message-ID: <521625AC.6050602@redhat.com> Date: Thu, 22 Aug 2013 16:52:28 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <5214DF5B.50203@redhat.com> <20130822055947.GB24870@in.ibm.com> <20130822074846.GC10412@stefanha-thinkpad.redhat.com> <5215D4A7.60501@redhat.com> <20130822095542.GA2755@in.ibm.com> <5215E150.7000800@redhat.com> <20130822102829.GB2755@in.ibm.com> <5215F2EF.4060106@redhat.com> <20130822132551.GC2755@in.ibm.com> <521611C7.7040809@redhat.com> <20130822140147.GD2755@in.ibm.com> In-Reply-To: <20130822140147.GD2755@in.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] block: Fix race in gluster_finish_aiocb List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: bharata@linux.vnet.ibm.com Cc: Kevin Wolf , Vijay Bellur , Stefan Hajnoczi , qemu-devel@nongnu.org, Stefan Hajnoczi , Asias He , MORITA Kazutaka Il 22/08/2013 16:01, Bharata B Rao ha scritto: >>>> EFAULT means the buffer address is invalid, I/O error would be EIO, but... >>>> >>>>> I remember this was one of the motivations to >>>>> handle this failure. >>>> >>>> ... this write is on the pipe, not on a disk. >>> >>> Right. Failure to complete the write on the pipe means that IO done to the >>> disk didn't complete and hence to the VM it is essentially a disk IO failure. >> >> The question is, can the write to the pipe actually fail? Not just "in >> practice not" according to the documented errors, it seems to me that it >> cannot. > > May be I am dragging this a bit, but since we are at it, let me make one last > observation here :) > > The buffer in question here is the GlusterAIOCB pointer that gets passed > back and forth between QEMU and gluster thro' glfs_pwritev_async and associated > callback gluster_finish_aiocb. No, it's not: retval = qemu_write_full(s->fds[GLUSTER_FD_WRITE], &acb, sizeof(acb)); The pointer that is passed to qemu_write_full is on the stack; it's the address of the acb variable. The _content_ of the buffer (which the kernel doesn't look at, so it's not relevant for generating EFAULT) is the GlusterAIOCB pointer. > Isn't there a possibility that gluster will > not give us back the same pointer during callback due to some errors on the > gluster side ? Unlikely but possible ? Then we would have already crashed on the line before: acb->ret = ret; which writes to the hypothetically corrupted pointer. But we cannot protect against memory corruption, or against bugs that violate the API contract at such a fundamental level. QEMU will SIGSEGV, but it wouldn't be the first time. Paolo