From: Pavel Begunkov <[email protected]>
To: Jens Axboe <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [PATCH] io_uring: fix invalid handler for double apoll
Date: Sun, 25 Oct 2020 19:54:47 +0000 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 25/10/2020 19:44, Jens Axboe wrote:
> On 10/25/20 1:32 PM, Pavel Begunkov wrote:
>> On 25/10/2020 19:18, Jens Axboe wrote:
>>> On 10/25/20 1:01 PM, Pavel Begunkov wrote:
>>>> On 25/10/2020 18:42, Jens Axboe wrote:
>>>>> On 10/25/20 10:24 AM, Pavel Begunkov wrote:
>>>>>> On 25/10/2020 15:53, Jens Axboe wrote:
>>>>>>> On 10/25/20 8:26 AM, Pavel Begunkov wrote:
>>>>>>>> io_poll_double_wake() is called for both: poll requests and as apoll
>>>>>>>> (internal poll to make rw and other requests), hence when it calls
>>>>>>>> __io_async_wake() it should use a right callback depending on the
>>>>>>>> current poll type.
>>>>>>>
>>>>>>> Can we do something like this instead? Untested...
>>>>>>
>>>>>> It should work, but looks less comprehensible. Though, it'll need
>>>>>
>>>>> Not sure I agree, with a comment it'd be nicer im ho:
>>>>
>>>> I don't really care enough to start a bikeshedding, let's get yours
>>>> tested and merged.
>>>
>>> Not really bikeshedding I think, we're not debating names of
>>> functions :-)
>>
>> It's just not so important, and it even may get removed in a month,
>> who knows.
>
> Well it might not or it might take longer, still nice to have the
> simplest fix...
Ok, then TLDR: my reasoning is that with poll->wait.func(), a person
who reads it needs to
a) go look up what's poll (assigned depending on the opcode),
b) then find out which wait.func callback it set. And it's not
as easy to associate __io_arm_poll_handler() call sites with cases
if you haven't seen this code before.
c) then go through io_{async,poll}_wake to finally find out that they
do almost the same thing, that's calling __io_async_wake().
I'm familiar with the code structure, but IMHO it's harder to
understand, if I'd be looking for the first time.
>
>>> My approach would need conditional clearing of ->private as well,
>>> as far as I can tell. I'll give it a spin.
>>
>> Maybe
>>
>> - poll->wait.func(wait, mode, sync, key);
>> + poll->wait.func(&poll->wait, mode, sync, key);
>
> Ah yeah, that looks better.
>
--
Pavel Begunkov
next prev parent reply other threads:[~2020-10-25 19:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-25 14:26 [PATCH] io_uring: fix invalid handler for double apoll Pavel Begunkov
2020-10-25 15:53 ` Jens Axboe
2020-10-25 16:24 ` Pavel Begunkov
2020-10-25 18:42 ` Jens Axboe
2020-10-25 19:01 ` Pavel Begunkov
2020-10-25 19:18 ` Jens Axboe
2020-10-25 19:32 ` Pavel Begunkov
2020-10-25 19:44 ` Jens Axboe
2020-10-25 19:54 ` Pavel Begunkov [this message]
2020-10-26 1:22 ` 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] \
[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