From: Kevin Wolf <kwolf@redhat.com>
To: Fabian Ebner <f.ebner@proxmox.com>
Cc: "open list:Linux io_uring" <qemu-block@nongnu.org>,
Stefan Hajnoczi <stefanha@gmail.com>,
Julia Suvorova <jusual@redhat.com>,
qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
Aarushi Mehta <mehta.aaru20@gmail.com>,
Stefano Garzarella <sgarzare@redhat.com>
Subject: Re: [PATCH v2] block/io_uring: resubmit when result is -EAGAIN
Date: Mon, 2 Aug 2021 14:40:36 +0200 [thread overview]
Message-ID: <YQfnxLROKL/JUKyF@redhat.com> (raw)
In-Reply-To: <20210729091029.65369-1-f.ebner@proxmox.com>
Am 29.07.2021 um 11:10 hat Fabian Ebner geschrieben:
> Linux SCSI can throw spurious -EAGAIN in some corner cases in its
> completion path, which will end up being the result in the completed
> io_uring request.
>
> Resubmitting such requests should allow block jobs to complete, even
> if such spurious errors are encountered.
>
> Co-authored-by: Stefan Hajnoczi <stefanha@gmail.com>
> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
> Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
> ---
>
> Changes from v1:
> * Focus on what's relevant for the patch itself in the commit
> message.
> * Add Stefan's comment.
> * Add Stefano's R-b tag (I hope that's fine, since there was no
> change code-wise).
>
> block/io_uring.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/block/io_uring.c b/block/io_uring.c
> index 00a3ee9fb8..dfa475cc87 100644
> --- a/block/io_uring.c
> +++ b/block/io_uring.c
> @@ -165,7 +165,21 @@ static void luring_process_completions(LuringState *s)
> total_bytes = ret + luringcb->total_read;
>
> if (ret < 0) {
> - if (ret == -EINTR) {
> + /*
> + * Only writev/readv/fsync requests on regular files or host block
> + * devices are submitted. Therefore -EAGAIN is not expected but it's
> + * known to happen sometimes with Linux SCSI. Submit again and hope
> + * the request completes successfully.
> + *
> + * For more information, see:
> + * https://lore.kernel.org/io-uring/20210727165811.284510-3-axboe@kernel.dk/T/#u
> + *
> + * If the code is changed to submit other types of requests in the
> + * future, then this workaround may need to be extended to deal with
> + * genuine -EAGAIN results that should not be resubmitted
> + * immediately.
> + */
> + if (ret == -EINTR || ret == -EAGAIN) {
> luring_resubmit(s, luringcb);
> continue;
> }
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Question about the preexisting code, though: luring_resubmit() requires
that the caller calls ioq_submit() later so that the request doesn't
just sit in a queue without getting any attention, but actually gets
submitted to the kernel.
In the call chain ioq_submit() -> luring_process_completions() ->
luring_resubmit(), who takes care of that?
Kevin
next prev parent reply other threads:[~2021-08-02 12:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-29 9:10 [PATCH v2] block/io_uring: resubmit when result is -EAGAIN Fabian Ebner
2021-07-29 9:54 ` Stefano Garzarella
2021-07-29 16:15 ` Stefan Hajnoczi
2021-08-02 12:40 ` Kevin Wolf [this message]
2021-08-04 14:50 ` Stefano Garzarella
2021-08-04 16:52 ` Kevin Wolf
2021-08-05 8:31 ` Stefano Garzarella
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=YQfnxLROKL/JUKyF@redhat.com \
--to=kwolf@redhat.com \
--cc=f.ebner@proxmox.com \
--cc=jusual@redhat.com \
--cc=mehta.aaru20@gmail.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@redhat.com \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.