From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35711)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1VCRi3-0004Ne-3M
	for qemu-devel@nongnu.org; Thu, 22 Aug 2013 06:01:49 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1VCRhx-00031o-4z
	for qemu-devel@nongnu.org; Thu, 22 Aug 2013 06:01:43 -0400
Received: from mx1.redhat.com ([209.132.183.28]:19805)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1VCRhw-00031E-UZ
	for qemu-devel@nongnu.org; Thu, 22 Aug 2013 06:01:37 -0400
Message-ID: <5215E150.7000800@redhat.com>
Date: Thu, 22 Aug 2013 12:00:48 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1377050567-19122-1-git-send-email-asias@redhat.com>
	<20130821152440.GB18303@stefanha-thinkpad.redhat.com>
	<5214DF5B.50203@redhat.com> <20130822055947.GB24870@in.ibm.com>
	<20130822074846.GC10412@stefanha-thinkpad.redhat.com>
	<5215D4A7.60501@redhat.com> <20130822095542.GA2755@in.ibm.com>
In-Reply-To: <20130822095542.GA2755@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: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: bharata@linux.vnet.ibm.com
Cc: Kevin Wolf <kwolf@redhat.com>, Vijay Bellur <vbellur@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>, Asias He <asias@redhat.com>, MORITA Kazutaka <morita.kazutaka@lab.ntt.co.jp>

Il 22/08/2013 11:55, Bharata B Rao ha scritto:
> This was the first apporach I had. I used to abort when writes to pipe
> fail. But there were concerns raised about handling the failures gracefully
> and hence we ended up doing all that error handling of completing the aio
> with -EIO, closing the pipe and making the disk inaccessible.
> 
>> > Under what circumstances could it happen?
> Not very sure, I haven't seen that happening. I had to manually inject
> faults to test this error path and verify the graceful recovery.

Looking at write(2), it looks like it is impossible

       EAGAIN or EWOULDBLOCK
               can't happen, blocking file descriptor

       EBADF, EPIPE
               shouldn't happen since the device is drained before
               calling qemu_gluster_close.

       EDESTADDRREQ, EDQUOT, EFBIG, EIO, ENOSPC
               cannot happen for pipes

       EFAULT
               abort would be fine

       EINTR
               handled by qemu_write_full

       EINVAL
               cannot happen (unless the pipe is closed and the
               file descriptor recycled, but see EBADF above)

The pipe(7) man page doesn't seem to add any more errors.

Paolo