public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: io-uring <[email protected]>
Cc: Pavel Begunkov <[email protected]>
Subject: [PATCH] io_uring: assign non-fixed early for async work
Date: Sun, 1 May 2022 21:27:01 -0600	[thread overview]
Message-ID: <[email protected]> (raw)

We defer file assignment to ensure that fixed files work with links
between a direct accept/open and the links that follow it. But this has
the side effect that normal file assignment is then not complete by the
time that request submission has been done.

For deferred execution, if the file is a regular file, assign it when
we do the async prep anyway.

Signed-off-by: Jens Axboe <[email protected]>

---

Undecided if we really need this, but as it stands, if the app does:

io_uring_prep_read(sqe, fd, buf, sizeof(buf), 0);
sqe->flags |= IOSQE_ASYNC;
io_uring_submit(ring);
close(fd);

then before the deferred assignment, this would've worked as the file
assignment would have been done before io_uring_submit() returns. Now,
this isn't the case, and we'll get -EBADF. Another case would be that
if you do:

io_uring_prep_read(sqe, fd, buf, sizeof(buf), 0);
sqe->flags |= IOSQE_ASYNC;
io_uring_submit(ring);

close(fd);
fd = open(something else);

and the new fd has the same value as the old one, then the above sqe
could get either one in the read. With this patch, we'll consistently
get the old fd as we did before.

It's worth nothing that IORING_SETUP_SQPOLL has the same behavior, both
before and after that deferred file assignment. Though that's more
expected, and the general contract between the app and the kernel for
SQPOLL is that submission side state needs to be valid until the
completion as the app doesn't know when the sqe has been consumed.


diff --git a/fs/io_uring.c b/fs/io_uring.c
index e01f595f5b7d..7d73b8ecc2e2 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -6947,7 +6947,12 @@ static int io_req_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe)
 
 static int io_req_prep_async(struct io_kiocb *req)
 {
-	if (!io_op_defs[req->opcode].needs_async_setup)
+	const struct io_op_def *def = &io_op_defs[req->opcode];
+
+	/* assign early for deferred execution for non-fixed file */
+	if (def->needs_file && !(req->flags & REQ_F_FIXED_FILE))
+		req->file = io_file_get_normal(req, req->cqe.fd);
+	if (!def->needs_async_setup)
 		return 0;
 	if (WARN_ON_ONCE(req_has_async_data(req)))
 		return -EFAULT;

-- 
Jens Axboe


                 reply	other threads:[~2022-05-02  3:27 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox