[PATCH 1/1] io_uring/rw: reissue only from the same task

[PATCH 1/1] io_uring/rw: reissue only from the same task

[Pavel Begunkov]

io_rw_should_reissue() tries to propagate EAGAIN back to io_uring when
happens off the submission path, which is when it's staying within the
same task, and so thread group checks don't make much sense.

Cc: stable@vger.kernel.org
Fixes: ef04688871f33 ("io_uring: don't block level reissue off completion path")
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
 io_uring/rw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/io_uring/rw.c b/io_uring/rw.c
index ca1b19d3d142..4d5aeff79130 100644
--- a/io_uring/rw.c
+++ b/io_uring/rw.c
@@ -485,7 +485,7 @@ static bool io_rw_should_reissue(struct io_kiocb *req)
 	 * Play it safe and assume not safe to re-import and reissue if we're
 	 * not in the original thread group (or in task context).
 	 */
-	if (!same_thread_group(req->tctx->task, current) || !in_task())
+	if (req->tctx->task != current || !in_task())
 		return false;
 	return true;
 }
-- 
2.47.1

Re: [PATCH 1/1] io_uring/rw: reissue only from the same task

[Jens Axboe]

On 1/7/25 7:11 AM, Pavel Begunkov wrote:
> io_rw_should_reissue() tries to propagate EAGAIN back to io_uring when
> happens off the submission path, which is when it's staying within the
> same task, and so thread group checks don't make much sense.

Since there's the nvme multipath retry issue, let's skip this for now
and focus on sanitizing the retry stuff for 6.14 with an eye towards
just backporting that to 6.10+ where we have some sanity on the
import side with persistent data across issues.

-- 
Jens Axboe

Re: [PATCH 1/1] io_uring/rw: reissue only from the same task

[Pavel Begunkov]

On 1/7/25 14:31, Jens Axboe wrote:
> On 1/7/25 7:11 AM, Pavel Begunkov wrote:
>> io_rw_should_reissue() tries to propagate EAGAIN back to io_uring when
>> happens off the submission path, which is when it's staying within the
>> same task, and so thread group checks don't make much sense.
> 
> Since there's the nvme multipath retry issue, let's skip this for now
> and focus on sanitizing the retry stuff for 6.14 with an eye towards
> just backporting that to 6.10+ where we have some sanity on the
> import side with persistent data across issues.

Agree, and as mentioned the patch is troubled anyway. And something
tells me it'll turn into more of a rw request "lifetime" change rather
than iovec / buffer persistency thing.

-- 
Pavel Begunkov