diff mbox series

[v2] io_uring: fix CQ waiting timeout handling

Message ID f7bffddd71b08f28a877d44d37ac953ddb01590d.1672915663.git.asml.silence@gmail.com (mailing list archive)
State New
Headers show
Series [v2] io_uring: fix CQ waiting timeout handling | expand

Commit Message

Pavel Begunkov Jan. 5, 2023, 10:49 a.m. UTC
Jiffy to ktime CQ waiting conversion broke how we treat timeouts, in
particular we rearm it anew every time we get into
io_cqring_wait_schedule() without adjusting the timeout. Waiting for 2
CQEs and getting a task_work in the middle may double the timeout value,
or even worse in some cases task may wait indefinitely.

Cc: stable@vger.kernel.org
Fixes: 228339662b398 ("io_uring: don't convert to jiffies for waiting on timeouts")
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---

v2: rebase

 io_uring/io_uring.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Jens Axboe Jan. 5, 2023, 3:05 p.m. UTC | #1
On Thu, 05 Jan 2023 10:49:15 +0000, Pavel Begunkov wrote:
> Jiffy to ktime CQ waiting conversion broke how we treat timeouts, in
> particular we rearm it anew every time we get into
> io_cqring_wait_schedule() without adjusting the timeout. Waiting for 2
> CQEs and getting a task_work in the middle may double the timeout value,
> or even worse in some cases task may wait indefinitely.
> 
> 
> [...]

Applied, thanks!

[1/1] io_uring: fix CQ waiting timeout handling
      commit: 12521a5d5cb7ff0ad43eadfc9c135d86e1131fa8

Best regards,
Xiaoguang Wang Jan. 11, 2023, 6:39 a.m. UTC | #2
hello,

> Jiffy to ktime CQ waiting conversion broke how we treat timeouts, in
> particular we rearm it anew every time we get into
> io_cqring_wait_schedule() without adjusting the timeout. Waiting for 2
> CQEs and getting a task_work in the middle may double the timeout value,
> or even worse in some cases task may wait indefinitely.
>
> Cc: stable@vger.kernel.org
> Fixes: 228339662b398 ("io_uring: don't convert to jiffies for waiting on timeouts")
> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
> ---
>
> v2: rebase
>
>  io_uring/io_uring.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
> index 472574192dd6..2ac1cd8d23ea 100644
> --- a/io_uring/io_uring.c
> +++ b/io_uring/io_uring.c
> @@ -2470,7 +2470,7 @@ int io_run_task_work_sig(struct io_ring_ctx *ctx)
>  /* when returns >0, the caller should retry */
>  static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx,
>  					  struct io_wait_queue *iowq,
> -					  ktime_t timeout)
> +					  ktime_t *timeout)
>  {
>  	int ret;
>  	unsigned long check_cq;
> @@ -2488,7 +2488,7 @@ static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx,
>  		if (check_cq & BIT(IO_CHECK_CQ_DROPPED_BIT))
>  			return -EBADR;
>  	}
> -	if (!schedule_hrtimeout(&timeout, HRTIMER_MODE_ABS))
> +	if (!schedule_hrtimeout(timeout, HRTIMER_MODE_ABS))
>  		return -ETIME;
>  
>  	/*
> @@ -2564,7 +2564,7 @@ static int io_cqring_wait(struct io_ring_ctx *ctx, int min_events,
>  		}
>  		prepare_to_wait_exclusive(&ctx->cq_wait, &iowq.wq,
>  						TASK_INTERRUPTIBLE);
> -		ret = io_cqring_wait_schedule(ctx, &iowq, timeout);
> +		ret = io_cqring_wait_schedule(ctx, &iowq, &timeout);
>  		if (__io_cqring_events_user(ctx) >= min_events)
>  			break;
>  		cond_resched();
Does this bug result in any real issues?
io_cqring_wait_schedule() calls schedule_hrtimeout(), but seems that
schedule_hrtimeout() and its child functions don't modify timeout or expires
at all, so I wonder how this patch works. Thanks.

Regards,
Xiaoguang Wang
Pavel Begunkov Jan. 11, 2023, 2:44 p.m. UTC | #3
On 1/11/23 06:39, Xiaoguang Wang wrote:
> hello,
> 
>>   	/*
>> @@ -2564,7 +2564,7 @@ static int io_cqring_wait(struct io_ring_ctx *ctx, int min_events,
>>   		}
>>   		prepare_to_wait_exclusive(&ctx->cq_wait, &iowq.wq,
>>   						TASK_INTERRUPTIBLE);
>> -		ret = io_cqring_wait_schedule(ctx, &iowq, timeout);
>> +		ret = io_cqring_wait_schedule(ctx, &iowq, &timeout);
>>   		if (__io_cqring_events_user(ctx) >= min_events)
>>   			break;
>>   		cond_resched();
> Does this bug result in any real issues?
> io_cqring_wait_schedule() calls schedule_hrtimeout(), but seems that
> schedule_hrtimeout() and its child functions don't modify timeout or expires
> at all, so I wonder how this patch works. Thanks.

Looked it up, you're right, I guess passing a pointer and one example
using it this way convinced me that it should be the case. Even more
interesting that as there is only HRTIMER_MODE_ABS and no relative
modes as before (IIRC) it wasn't a bug in the first place. Thanks
for taking a look
diff mbox series

Patch

diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 472574192dd6..2ac1cd8d23ea 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -2470,7 +2470,7 @@  int io_run_task_work_sig(struct io_ring_ctx *ctx)
 /* when returns >0, the caller should retry */
 static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx,
 					  struct io_wait_queue *iowq,
-					  ktime_t timeout)
+					  ktime_t *timeout)
 {
 	int ret;
 	unsigned long check_cq;
@@ -2488,7 +2488,7 @@  static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx,
 		if (check_cq & BIT(IO_CHECK_CQ_DROPPED_BIT))
 			return -EBADR;
 	}
-	if (!schedule_hrtimeout(&timeout, HRTIMER_MODE_ABS))
+	if (!schedule_hrtimeout(timeout, HRTIMER_MODE_ABS))
 		return -ETIME;
 
 	/*
@@ -2564,7 +2564,7 @@  static int io_cqring_wait(struct io_ring_ctx *ctx, int min_events,
 		}
 		prepare_to_wait_exclusive(&ctx->cq_wait, &iowq.wq,
 						TASK_INTERRUPTIBLE);
-		ret = io_cqring_wait_schedule(ctx, &iowq, timeout);
+		ret = io_cqring_wait_schedule(ctx, &iowq, &timeout);
 		if (__io_cqring_events_user(ctx) >= min_events)
 			break;
 		cond_resched();