Re: [Qemu-devel] [PATCH] block: Fix race in gluster_finish_aiocb

[Bharata B Rao <bharata@linux.vnet.ibm.com>]

On Thu, Aug 22, 2013 at 03:27:35PM +0200, Paolo Bonzini wrote:
> >>>> 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
> >>>
> >>> In the case where we have separate system and data disks and if error (EFAULT)
> >>> happens for the data disk, don't we want to keep the VM up by gracefully
> >>> disabling IO to the data disk ?
> >>
> >> 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. 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 ?

Regards,
Bharata.