io_[p]getevents syscall should return -EINVAL if if timeout is out of
range, add this validity check.
Signed-off-by: zhangyi (F) <[email protected]>
---
fs/aio.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 01e0fb9..dd967a0 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -2031,10 +2031,17 @@ static long do_io_getevents(aio_context_t ctx_id,
struct io_event __user *events,
struct timespec64 *ts)
{
- ktime_t until = ts ? timespec64_to_ktime(*ts) : KTIME_MAX;
- struct kioctx *ioctx = lookup_ioctx(ctx_id);
+ ktime_t until = KTIME_MAX;
+ struct kioctx *ioctx = NULL;
long ret = -EINVAL;
+ if (ts) {
+ if (!timespec64_valid(ts))
+ return ret;
+ until = timespec64_to_ktime(*ts);
+ }
+
+ ioctx = lookup_ioctx(ctx_id);
if (likely(ioctx)) {
if (likely(min_nr <= nr && min_nr >= 0))
ret = read_events(ioctx, min_nr, nr, events, until);
--
2.7.4
"zhangyi (F)" <[email protected]> writes:
> io_[p]getevents syscall should return -EINVAL if if timeout is out of
> range, add this validity check.
>
> Signed-off-by: zhangyi (F) <[email protected]>
> ---
> fs/aio.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/fs/aio.c b/fs/aio.c
> index 01e0fb9..dd967a0 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -2031,10 +2031,17 @@ static long do_io_getevents(aio_context_t ctx_id,
> struct io_event __user *events,
> struct timespec64 *ts)
> {
> - ktime_t until = ts ? timespec64_to_ktime(*ts) : KTIME_MAX;
> - struct kioctx *ioctx = lookup_ioctx(ctx_id);
> + ktime_t until = KTIME_MAX;
> + struct kioctx *ioctx = NULL;
> long ret = -EINVAL;
>
> + if (ts) {
> + if (!timespec64_valid(ts))
> + return ret;
> + until = timespec64_to_ktime(*ts);
> + }
> +
> + ioctx = lookup_ioctx(ctx_id);
> if (likely(ioctx)) {
> if (likely(min_nr <= nr && min_nr >= 0))
> ret = read_events(ioctx, min_nr, nr, events, until);
Reviewed-by: Jeff Moyer <[email protected]>
The previous suggestion[1] of fixing the helpers never materialized, so
let's just get this fixed, already.
-Jeff
[1] https://marc.info/?l=linux-fsdevel&m=152209450618587&w=2
Al, can you take this through your tree?
Thanks,
Jeff
Jeff Moyer <[email protected]> writes:
> "zhangyi (F)" <[email protected]> writes:
>
>> io_[p]getevents syscall should return -EINVAL if if timeout is out of
>> range, add this validity check.
>>
>> Signed-off-by: zhangyi (F) <[email protected]>
>> ---
>> fs/aio.c | 11 +++++++++--
>> 1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/aio.c b/fs/aio.c
>> index 01e0fb9..dd967a0 100644
>> --- a/fs/aio.c
>> +++ b/fs/aio.c
>> @@ -2031,10 +2031,17 @@ static long do_io_getevents(aio_context_t ctx_id,
>> struct io_event __user *events,
>> struct timespec64 *ts)
>> {
>> - ktime_t until = ts ? timespec64_to_ktime(*ts) : KTIME_MAX;
>> - struct kioctx *ioctx = lookup_ioctx(ctx_id);
>> + ktime_t until = KTIME_MAX;
>> + struct kioctx *ioctx = NULL;
>> long ret = -EINVAL;
>>
>> + if (ts) {
>> + if (!timespec64_valid(ts))
>> + return ret;
>> + until = timespec64_to_ktime(*ts);
>> + }
>> +
>> + ioctx = lookup_ioctx(ctx_id);
>> if (likely(ioctx)) {
>> if (likely(min_nr <= nr && min_nr >= 0))
>> ret = read_events(ioctx, min_nr, nr, events, until);
>
> Reviewed-by: Jeff Moyer <[email protected]>
>
> The previous suggestion[1] of fixing the helpers never materialized, so
> let's just get this fixed, already.
>
> -Jeff
>
> [1] https://marc.info/?l=linux-fsdevel&m=152209450618587&w=2
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-aio' in
> the body to [email protected]. For more info on Linux AIO,
> see: http://www.kvack.org/aio/
> Don't email: <a href=mailto:"[email protected]">[email protected]</a>
On Mon, Jul 29, 2019 at 10:57:41AM -0400, Jeff Moyer wrote:
> Al, can you take this through your tree?
Umm... Can do, but I had an impression that Arnd and Deepa
had a tree for timespec-related work. OTOH, it had been
relatively quiet last cycle, so... If they have nothing
in the area, I can take it through vfs.git.
Al Viro <[email protected]> writes:
> On Mon, Jul 29, 2019 at 10:57:41AM -0400, Jeff Moyer wrote:
>> Al, can you take this through your tree?
>
> Umm... Can do, but I had an impression that Arnd and Deepa
> had a tree for timespec-related work. OTOH, it had been
> relatively quiet last cycle, so... If they have nothing
> in the area, I can take it through vfs.git.
Hmm, okay. Yi, can you repost the patch, adding my Reviewed-by tag, and
CC-ing Arnd and Deepa:
Arnd Bergmann <[email protected]>
Deepa Dinamani <[email protected]>
Thanks!
Jeff
On 2019/7/29 23:59, Jeff Moyer Wrote:
> Al Viro <[email protected]> writes:
>
>> On Mon, Jul 29, 2019 at 10:57:41AM -0400, Jeff Moyer wrote:
>>> Al, can you take this through your tree?
>>
>> Umm... Can do, but I had an impression that Arnd and Deepa
>> had a tree for timespec-related work. OTOH, it had been
>> relatively quiet last cycle, so... If they have nothing
>> in the area, I can take it through vfs.git.
>
> Hmm, okay. Yi, can you repost the patch, adding my Reviewed-by tag, and
> CC-ing Arnd and Deepa:
>
Yes, will do.
Thanks,
Yi.
Hi, Al, could you please consider applying this patch ?
Thanks,
Yi.
On 2019/7/29 23:47, Al Viro wrote:
> On Mon, Jul 29, 2019 at 10:57:41AM -0400, Jeff Moyer wrote:
>> Al, can you take this through your tree?
>
> Umm... Can do, but I had an impression that Arnd and Deepa
> had a tree for timespec-related work. OTOH, it had been
> relatively quiet last cycle, so... If they have nothing
> in the area, I can take it through vfs.git.
>
> .
>