public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Caleb Sander Mateos <[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 09:19:33 -0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <CADUfDZo-mqM_PwoPK3_JX14QY3sQfVXnSwD=+30tdcAiD9fTJg@mail.gmail.com>

On 2/13/25 9:16 AM, Caleb Sander Mateos wrote:
> 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.

I did ponder that (passing in the sqe and storing once), but didn't
figure it'd be worthwhile to do. But on second thought, maybe we just do
it, passing in the sqe and letting it be assigned in there. I'll send
out a v2.

-- 
Jens Axboe

      reply	other threads:[~2025-02-13 16:19 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
2025-02-13 16:19   ` Jens Axboe [this message]

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