| Message ID | 92b0a330-4782-45e9-8de7-3b90a94208c2@kernel.dk (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | io_uring/rw: ensure reissue path is correctly handled for IOPOLL | expand |
On 05/03/2025 21:06, Jens Axboe wrote: > The IOPOLL path posts CQEs when the io_kiocb is marked as completed, > so it cannot rely on the usual retry that non-IOPOLL requests do for > read/write requests. > > If -EAGAIN is received and the request should be retried, go through > the normal completion path and let the normal flush logic catch it and > reissue it, like what is done for !IOPOLL reads or writes. > > Fixes: d803d123948f ("io_uring/rw: handle -EAGAIN retry at IO completion time") > Reported-by: John Garry<john.g.garry@oracle.com> > Link:https://urldefense.com/v3/__https://lore.kernel.org/io- > uring/2b43ccfa-644d-4a09-8f8f-39ad71810f41@oracle.com/__;!! > ACWV5N9M2RV99hQ!J4rCZomS7jntxigOWFGkQC3hFMb5EZf3-aZG4hZCB6n_quTKHse9g- > WSxf46gMXpEfyzjaAQKTff2J9o0pg$ > Signed-off-by: Jens Axboe<axboe@kernel.dk> This solves the issue which I was seeing, so: Tested-by: John Garry <john.g.garry@oracle.com> cheers
On 3/6/25 3:12 AM, John Garry wrote: > On 05/03/2025 21:06, Jens Axboe wrote: >> The IOPOLL path posts CQEs when the io_kiocb is marked as completed, >> so it cannot rely on the usual retry that non-IOPOLL requests do for >> read/write requests. >> >> If -EAGAIN is received and the request should be retried, go through >> the normal completion path and let the normal flush logic catch it and >> reissue it, like what is done for !IOPOLL reads or writes. >> >> Fixes: d803d123948f ("io_uring/rw: handle -EAGAIN retry at IO completion time") >> Reported-by: John Garry<john.g.garry@oracle.com> >> Link:https://urldefense.com/v3/__https://lore.kernel.org/io- uring/2b43ccfa-644d-4a09-8f8f-39ad71810f41@oracle.com/__;!! ACWV5N9M2RV99hQ!J4rCZomS7jntxigOWFGkQC3hFMb5EZf3-aZG4hZCB6n_quTKHse9g- WSxf46gMXpEfyzjaAQKTff2J9o0pg$ Signed-off-by: Jens Axboe<axboe@kernel.dk> > > This solves the issue which I was seeing, so: > > Tested-by: John Garry <john.g.garry@oracle.com> Great, thanks for testing!
diff --git a/io_uring/rw.c b/io_uring/rw.c index 9edc6baebd01..e5528cebcd06 100644 --- a/io_uring/rw.c +++ b/io_uring/rw.c @@ -560,11 +560,10 @@ static void io_complete_rw_iopoll(struct kiocb *kiocb, long res) if (kiocb->ki_flags & IOCB_WRITE) io_req_end_write(req); if (unlikely(res != req->cqe.res)) { - if (res == -EAGAIN && io_rw_should_reissue(req)) { + if (res == -EAGAIN && io_rw_should_reissue(req)) req->flags |= REQ_F_REISSUE | REQ_F_BL_NO_RECYCLE; - return; - } - req->cqe.res = res; + else + req->cqe.res = res; } /* order with io_iopoll_complete() checking ->iopoll_completed */
The IOPOLL path posts CQEs when the io_kiocb is marked as completed, so it cannot rely on the usual retry that non-IOPOLL requests do for read/write requests. If -EAGAIN is received and the request should be retried, go through the normal completion path and let the normal flush logic catch it and reissue it, like what is done for !IOPOLL reads or writes. Fixes: d803d123948f ("io_uring/rw: handle -EAGAIN retry at IO completion time") Reported-by: John Garry <john.g.garry@oracle.com> Link: https://lore.kernel.org/io-uring/2b43ccfa-644d-4a09-8f8f-39ad71810f41@oracle.com/ Signed-off-by: Jens Axboe <axboe@kernel.dk> ---