All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: nick@nickhill.org, io-uring@vger.kernel.org
Subject: Re: WRITEV with IOSQE_ASYNC broken?
Date: Fri, 4 Sep 2020 22:35:19 -0600	[thread overview]
Message-ID: <d8404079-fe7e-3f42-4460-22328b12b0fa@kernel.dk> (raw)
In-Reply-To: <fe3784cf-3389-6096-9dfd-f3aa8cd3a769@kernel.dk>

On 9/4/20 9:57 PM, Jens Axboe wrote:
> On 9/4/20 9:53 PM, Jens Axboe wrote:
>> On 9/4/20 9:22 PM, nick@nickhill.org wrote:
>>> Hi,
>>>
>>> I am helping out with the netty io_uring integration, and came across 
>>> some strange behaviour which seems like it might be a bug related to 
>>> async offload of read/write iovecs.
>>>
>>> Basically a WRITEV SQE seems to fail reliably with -BADADDRESS when the 
>>> IOSQE_ASYNC flag is set but works fine otherwise (everything else the 
>>> same). This is with 5.9.0-rc3.
>>
>> Do you see it just on 5.9-rc3, or also 5.8? Just curious... But that is
>> very odd in any case, ASYNC writev is even part of the regular tests.
>> Any sort of deferral, be it explicit via ASYNC or implicit through
>> needing to retry, saves all the needed details to retry without
>> needing any of the original context.
>>
>> Can you narrow down what exactly is being written - like file type,
>> buffered/O_DIRECT, etc. What file system, what device is hosting it.
>> The more details the better, will help me narrow down what is going on.
> 
> Forgot, also size of the IO (both total, but also number of iovecs in
> that particular request.
> 
> Essentially all the details that I would need to recreate what you're
> seeing.

Turns out there was a bug in the explicit handling, new in the current
-rc series. Can you try and add the below?

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 0d7be2e9d005..000ae2acfd58 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -2980,14 +2980,15 @@ static inline int io_rw_prep_async(struct io_kiocb *req, int rw,
 				   bool force_nonblock)
 {
 	struct io_async_rw *iorw = &req->io->rw;
+	struct iovec *iov;
 	ssize_t ret;
 
-	iorw->iter.iov = iorw->fast_iov;
-	ret = __io_import_iovec(rw, req, (struct iovec **) &iorw->iter.iov,
-				&iorw->iter, !force_nonblock);
+	iorw->iter.iov = iov = iorw->fast_iov;
+	ret = __io_import_iovec(rw, req, &iov, &iorw->iter, !force_nonblock);
 	if (unlikely(ret < 0))
 		return ret;
 
+	iorw->iter.iov = iov;
 	io_req_map_rw(req, iorw->iter.iov, iorw->fast_iov, &iorw->iter);
 	return 0;
 }

-- 
Jens Axboe


  reply	other threads:[~2020-09-05  4:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-05  3:22 WRITEV with IOSQE_ASYNC broken? nick
2020-09-05  3:53 ` Jens Axboe
2020-09-05  3:57   ` Jens Axboe
2020-09-05  4:35     ` Jens Axboe [this message]
2020-09-05  5:50       ` Pavel Begunkov
2020-09-05  8:24         ` nick
2020-09-05  8:26           ` Norman Maurer
2020-09-05 14:28             ` Norman Maurer
2020-09-05 15:02               ` Jens Axboe
2020-09-05 15:10         ` Jens Axboe
2020-09-05  5:04     ` nick

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=d8404079-fe7e-3f42-4460-22328b12b0fa@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=nick@nickhill.org \
    /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.