From: Caleb Sander Mateos <[email protected]>
To: Keith Busch <[email protected]>
Cc: Jens Axboe <[email protected]>,
Pavel Begunkov <[email protected]>,
Riley Thomasson <[email protected]>,
[email protected], [email protected]
Subject: Re: [PATCH 0/2] uring_cmd SQE corruptions
Date: Wed, 12 Feb 2025 15:46:34 -0800 [thread overview]
Message-ID: <CADUfDZqa5v7Rb-EXp-v_iMXAESts8u-DisMtjdBEu2+kK-ykeQ@mail.gmail.com> (raw)
In-Reply-To: <Z60s3ryl5UotleV-@kbusch-mbp>
On Wed, Feb 12, 2025 at 3:21 PM Keith Busch <[email protected]> wrote:
>
> On Wed, Feb 12, 2025 at 03:07:30PM -0800, Caleb Sander Mateos wrote:
> >
> > Yes, we completely agree. We are working on incorporating Keith's
> > patchset now. It looks like there is still an open question about
> > whether userspace will need to enforce ordering between the requests
> > (either using linked operations or waiting for completions before
> > submitting the subsequent operations).
>
> In its current form, my series depends on you *not* using linked
> requests. I didn't think it would be a problem as it follows an existing
> pattern from the IORING_OP_FILES_UPDATE operation. That has to complete
> in its entirety before prepping any subsequent commands that reference
> the index, and using links would get the wrong results.
As implementers of a ublk server, we would also prefer the current
interface in your patch series! Having to explicitly order the
requests would definitely make the interface more cumbersome and
probably less performant. I was just saying that Ming and Pavel had
raised some concerns about guaranteeing the order in which io_uring
issues SQEs. IORING_OP_FILES_UPDATE is a good analogy. Do we have any
examples of how applications use it? Are they waiting for a
completion, linking it, or relying on io_uring to issue it
synchronously?
next prev parent reply other threads:[~2025-02-12 23:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 20:45 [PATCH 0/2] uring_cmd SQE corruptions Caleb Sander Mateos
2025-02-12 20:45 ` [PATCH 1/2] io_uring/uring_cmd: don't assume io_uring_cmd_data layout Caleb Sander Mateos
2025-02-12 20:45 ` [PATCH 2/2] io_uring/uring_cmd: switch sqe to async_data on EAGAIN Caleb Sander Mateos
2025-02-12 20:55 ` [PATCH 0/2] uring_cmd SQE corruptions Jens Axboe
2025-02-12 21:02 ` Jens Axboe
2025-02-12 21:58 ` Caleb Sander
2025-02-12 22:34 ` Jens Axboe
2025-02-12 22:52 ` Caleb Sander
2025-02-12 22:56 ` Jens Axboe
2025-02-12 21:54 ` Caleb Sander
2025-02-12 22:39 ` Jens Axboe
2025-02-12 23:07 ` Caleb Sander Mateos
2025-02-12 23:21 ` Keith Busch
2025-02-12 23:46 ` Caleb Sander Mateos [this message]
2025-02-12 23:55 ` Jens Axboe
2025-02-13 16:28 ` Pavel Begunkov
2025-02-13 16:11 ` Pavel Begunkov
2025-02-13 14:48 ` Pavel Begunkov
2025-02-13 18:13 ` 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=CADUfDZqa5v7Rb-EXp-v_iMXAESts8u-DisMtjdBEu2+kK-ykeQ@mail.gmail.com \
[email protected] \
[email protected] \
[email protected] \
[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