On Thu 09-09-10 15:49:19, Jeff Moyer wrote:
> Jan Kara <jack@xxxxxxx> 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@xxxxxxxxxx>
Thanks.
Honza
--
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
