From: Caleb Sander Mateos <[email protected]>
To: Jens Axboe <[email protected]>
Cc: io-uring <[email protected]>
Subject: Re: [PATCH] io_uring/uring_cmd: unconditionally copy SQEs at prep time
Date: Thu, 13 Feb 2025 08:16:14 -0800 [thread overview]
Message-ID: <CADUfDZo-mqM_PwoPK3_JX14QY3sQfVXnSwD=+30tdcAiD9fTJg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
On Thu, Feb 13, 2025 at 7:30 AM Jens Axboe <[email protected]> wrote:
>
> This isn't generally necessary, but conditions have been observed where
> SQE data is accessed from the original SQE after prep has been done and
> outside of the initial issue. Opcode prep handlers must ensure that any
> SQE related data is stable beyond the prep phase, but uring_cmd is a bit
> special in how it handles the SQE which makes it susceptible to reading
> stale data. If the application has reused the SQE before the original
> completes, then that can lead to data corruption.
>
> Down the line we can relax this again once uring_cmd has been sanitized
> a bit, and avoid unnecessarily copying the SQE.
>
> Reported-by: Caleb Sander Mateos <[email protected]>
> Signed-off-by: Jens Axboe <[email protected]>
>
> ---
>
> Let's just do the unconditional copy for now. I kept it on top of the
> other patches deliberately, as they tell a story of how we got there.
> This will 100% cover all cases, obviously, and then we can focus on
> future work on avoiding the copy when unnecessary without having any
> rush on that front.
Thanks, we appreciate you quickly addressing the corruption issue.
Reviewed-by: Caleb Sander Mateos <[email protected]>
>
> diff --git a/io_uring/uring_cmd.c b/io_uring/uring_cmd.c
> index 8af7780407b7..b78d050aaa3f 100644
> --- a/io_uring/uring_cmd.c
> +++ b/io_uring/uring_cmd.c
> @@ -186,9 +186,14 @@ static int io_uring_cmd_prep_setup(struct io_kiocb *req,
> cache->op_data = NULL;
>
> ioucmd->sqe = sqe;
> - /* defer memcpy until we need it */
> - if (unlikely(req->flags & REQ_F_FORCE_ASYNC))
> - io_uring_cmd_cache_sqes(req);
> + /*
> + * Unconditionally cache the SQE for now - this is only needed for
> + * requests that go async, but prep handlers must ensure that any
> + * sqe data is stable beyond prep. Since uring_cmd is special in
> + * that it doesn't read in per-op data, play it safe and ensure that
> + * any SQE data is stable beyond prep. This can later get relaxed.
> + */
> + io_uring_cmd_cache_sqes(req);
If you wanted to micro-optimize this, you could probably avoid the
double store to ioucmd->sqe (ioucmd->sqe = sqe above and ioucmd->sqe =
cache->sqes in io_uring_cmd_cache_sqes()). Because of the intervening
memcpy(), the compiler probably won't be able to eliminate the first
store. Before my change, ioucmd->sqe was only assigned once in
io_uring_cmd_prep_setup(). You could pass sqe into
io_uring_cmd_cache_sqes() instead of obtaining it from ioucmd->sqe.
The cost of an additional (cached) store is probably negligible,
though, so I am fine with the patch as is.
> return 0;
> }
>
> @@ -251,16 +256,8 @@ int io_uring_cmd(struct io_kiocb *req, unsigned int issue_flags)
> }
>
> ret = file->f_op->uring_cmd(ioucmd, issue_flags);
> - if (ret == -EAGAIN) {
> - struct io_uring_cmd_data *cache = req->async_data;
> -
> - if (ioucmd->sqe != cache->sqes)
> - io_uring_cmd_cache_sqes(req);
> - return -EAGAIN;
> - } else if (ret == -EIOCBQUEUED) {
> - return -EIOCBQUEUED;
> - }
> -
> + if (ret == -EAGAIN || ret == -EIOCBQUEUED)
> + return ret;
> if (ret < 0)
> req_set_fail(req);
> io_req_uring_cleanup(req, issue_flags);
> --
> Jens Axboe
>
next prev parent reply other threads:[~2025-02-13 16:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-13 15:30 [PATCH] io_uring/uring_cmd: unconditionally copy SQEs at prep time Jens Axboe
2025-02-13 16:16 ` Caleb Sander Mateos [this message]
2025-02-13 16:19 ` Jens Axboe
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 \
--in-reply-to='CADUfDZo-mqM_PwoPK3_JX14QY3sQfVXnSwD=+30tdcAiD9fTJg@mail.gmail.com' \
[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