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 |
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,
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
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 --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();
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(-)