From: Jens Axboe <axboe@kernel.dk>
To: Pavel Begunkov <asml.silence@gmail.com>,
nick@nickhill.org, io-uring@vger.kernel.org
Subject: Re: WRITEV with IOSQE_ASYNC broken?
Date: Sat, 5 Sep 2020 09:10:51 -0600 [thread overview]
Message-ID: <17c49959-c049-3586-6459-79c056f779ba@kernel.dk> (raw)
In-Reply-To: <484b5876-a2e6-3e02-a566-10c5a02241e8@gmail.com>
On 9/4/20 11:50 PM, Pavel Begunkov wrote:
> On 05/09/2020 07:35, Jens Axboe wrote:
>> 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?
>
> Hah, absolutely the same patch was in a series I was going to send
> today, but with a note that it works by luck so not a bug. Apparently,
> it is :)>
> BTW, const in iter->iov is guarding from such cases, yet another proof
> that const casts are evil.
Definitely, not a great idea to begin with...
--
Jens Axboe
next prev parent reply other threads:[~2020-09-05 15:11 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
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 [this message]
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=17c49959-c049-3586-6459-79c056f779ba@kernel.dk \
--to=axboe@kernel.dk \
--cc=asml.silence@gmail.com \
--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.