Re: [PATCH] aio: Do not return ERESTARTSYS as a result of AIO (v2)

[Jan Kara <jack@suse.cz>]

On Thu 09-09-10 15:49:19, Jeff Moyer wrote:
> Jan Kara <jack@suse.cz> writes:
> 
> > OCFS2 can return ERESTARTSYS from its write function when the process is
> > signalled while waiting for a cluster lock (and the filesystem is mounted with
> > intr mount option). Generally, it seems reasonable to allow filesystems to
> > return this error code from its IO functions. As we must not leak ERESTARTSYS
> > (and similar error codes) to userspace as a result of an AIO operation, we
> > have to properly convert it to EINTR inside AIO code (restarting the syscall
> > isn't really an option because other AIO could have been already submitted by
> > the same io_submit syscall).
> 
> I had responded to your last posting with:
> 
>   This is a confusing problem description.  First, I'm assuming you
>   actually experienced this, is that right?  Care to share the details of
>   that?
> 
> The above paragraph I think you addressed.  I'm still curious about
> this, though.  The submission path should be as non-blocking as
> possible.  I guess you can't really get around locking, though.  Was the
> problem witnessed when doing O_DIRECT or buffered AIO?
> 
>   Next, assuming we can get ERSTARTSYS and friends, it will be the return
>   code of a single iocb (reaped via io_getevents), not the return code of
>   the io_submit system call.  I'm not saying this is right, I'm just
>   saying that your description of the problem is misleading.
> 
> That objection stands, but just warrants correcting the problem description.
  Hmm, I tried to address that by saying:

As we must not leak ERESTARTSYS (and similar error codes) to userspace
as a result of an AIO operation
     ^^^^^^^^^^^^^^^^^^^^^^^^^^
by which I meant the result value in the iocb structure. But apparently
it's not explicit enough. So would you be happier with something like
"result received via io_getevents() syscall"?

> Anyway, the code itself looks fine.  ;-)
> 
> Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
  Thanks.

									Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR