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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jan Kara <jack@xxxxxxx> writes:

> On Thu 09-09-10 15:49:19, Jeff Moyer wrote:
>> Jan Kara <jack@xxxxxxx> writes:

>>   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"?

That part looks fine, no need to change it.  What tripped me up was this: 

  (restarting the syscall isn't really an option because other AIO could
  have been already submitted by the same io_submit syscall)

To me, that sounded like the result would be seen by io_submit instead
of io_getevents.

Cheers,
Jeff
--
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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux