From: Jens Axboe <[email protected]>
To: Pavel Begunkov <[email protected]>,
io-uring <[email protected]>
Subject: Re: [PATCH v2] io_uring/net: ensure async prep handlers always initialize ->done_io
Date: Sat, 16 Mar 2024 10:31:41 -0600 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 3/16/24 10:28 AM, Pavel Begunkov wrote:
> On 3/16/24 16:14, Jens Axboe wrote:
>> On 3/15/24 5:28 PM, Pavel Begunkov wrote:
>>> On 3/15/24 23:25, Jens Axboe wrote:
>>>> On 3/15/24 5:19 PM, Pavel Begunkov wrote:
>>>>> On 3/15/24 23:13, Pavel Begunkov wrote:
>>>>>> On 3/15/24 23:09, Pavel Begunkov wrote:
>>>>>>> On 3/15/24 22:48, Jens Axboe wrote:
>>>>>>>> If we get a request with IOSQE_ASYNC set, then we first run the prep
>>>>>>>> async handlers. But if we then fail setting it up and want to post
>>>>>>>> a CQE with -EINVAL, we use ->done_io. This was previously guarded with
>>>>>>>> REQ_F_PARTIAL_IO, and the normal setup handlers do set it up before any
>>>>>>>> potential errors, but we need to cover the async setup too.
>>>>>>>
>>>>>>> You can hit io_req_defer_failed() { opdef->fail(); }
>>>>>>> off of an early submission failure path where def->prep has
>>>>>>> not yet been called, I don't think the patch will fix the
>>>>>>> problem.
>>>>>>>
>>>>>>> ->fail() handlers are fragile, maybe we should skip them
>>>>>>> if def->prep() wasn't called. Not even compile tested:
>>>>>>>
>>>>>>>
>>>>>>> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
>>>>>>> index 846d67a9c72e..56eed1490571 100644
>>>>>>> --- a/io_uring/io_uring.c
>>>>>>> +++ b/io_uring/io_uring.c
>>>>> [...]
>>>>>>> def->fail(req);
>>>>>>> io_req_complete_defer(req);
>>>>>>> }
>>>>>>> @@ -2201,8 +2201,7 @@ static int io_init_req(struct io_ring_ctx *ctx, struct io_kiocb *req,
>>>>>>> }
>>>>>>> req->flags |= REQ_F_CREDS;
>>>>>>> }
>>>>>>> -
>>>>>>> - return def->prep(req, sqe);
>>>>>>> + return 0;
>>>>>>> }
>>>>>>>
>>>>>>> static __cold int io_submit_fail_init(const struct io_uring_sqe *sqe,
>>>>>>> @@ -2250,8 +2249,15 @@ static inline int io_submit_sqe(struct io_ring_ctx *ctx, struct io_kiocb *req,
>>>>>>> int ret;
>>>>>>>
>>>>>>> ret = io_init_req(ctx, req, sqe);
>>>>>>> - if (unlikely(ret))
>>>>>>> + if (unlikely(ret)) {
>>>>>>> +fail:
>>>>>
>>>>> Obvious the diff is crap, but still bugging me enough to write
>>>>> that the label should've been one line below, otherwise we'd
>>>>> flag after ->prep as well.
>>>>
>>>> It certainly needs testing :-)
>>>>
>>>> We can go either way - patch up the net thing, or do a proper EARLY_FAIL
>>>> and hopefully not have to worry about it again. Do you want to clean it
>>>> up, test it, and send it out?
>>>
>>> I'd rather leave it to you, I suspect it wouldn't fix the syzbot
>>> report w/o fiddling with done_io as in your patch.
>>
>> I gave this a shot, but some fail handlers do want to get called. But
>
> Which one and/or which part of it?
send zc
I think the sanest is:
1) Opcode handlers should always initialize whatever they need before
failure
2) If we fail before ->prep, don't call ->fail
Yes that doesn't cover the case where opcode handlers do stupid things
like use opcode members in fail if they fail the prep, but that should
be the smallest part.
--
Jens Axboe
next prev parent reply other threads:[~2024-03-16 16:31 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-15 22:48 [PATCH v2] io_uring/net: ensure async prep handlers always initialize ->done_io Jens Axboe
2024-03-15 23:09 ` Pavel Begunkov
2024-03-15 23:13 ` Pavel Begunkov
2024-03-15 23:19 ` Pavel Begunkov
2024-03-15 23:25 ` Jens Axboe
2024-03-15 23:28 ` Pavel Begunkov
2024-03-15 23:53 ` Jens Axboe
2024-03-16 16:14 ` Jens Axboe
2024-03-16 16:28 ` Pavel Begunkov
2024-03-16 16:31 ` Jens Axboe [this message]
2024-03-16 16:32 ` Pavel Begunkov
2024-03-16 16:34 ` Pavel Begunkov
2024-03-16 16:36 ` Jens Axboe
2024-03-16 16:36 ` Pavel Begunkov
2024-03-16 16:40 ` Pavel Begunkov
2024-03-16 16:42 ` Jens Axboe
2024-03-16 16:46 ` Pavel Begunkov
2024-03-16 16:51 ` Jens Axboe
2024-03-16 16:57 ` Pavel Begunkov
2024-03-16 17:01 ` Jens Axboe
2024-03-16 17:42 ` Pavel Begunkov
2024-03-16 23:58 ` Jens Axboe
2024-03-17 20:45 ` Pavel Begunkov
2024-03-15 23: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 \
[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