Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [GIT PULL] io_uring fix for 5.7-rc3
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     io-uring <io-uring@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <156f8353-5841-39ad-3bc2-af9cadac3c71@kernel.dk>
 <CAHk-=wibcCGvPy=PjevdSzEtzrYPWJnLo+t=S3zy3AQ5+NNeEg@mail.gmail.com>
From:   Jens Axboe <axboe@kernel.dk>
Message-ID: <f903c9de-cec8-0a3e-efae-a3d37b6db4ad@kernel.dk>
Date:   Fri, 24 Apr 2020 14:11:54 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CAHk-=wibcCGvPy=PjevdSzEtzrYPWJnLo+t=S3zy3AQ5+NNeEg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 4/24/20 2:03 PM, Linus Torvalds wrote:
> On Fri, Apr 24, 2020 at 11:03 AM Jens Axboe <axboe@kernel.dk> wrote:
>>
>> Single fixup for a change that went into -rc2, please pull.
> 
> I'd like to point out that this was exactly the code that I pointed to
> as being badly written and hard to understand:
> 
>  "That whole apoll thing is disgusting.
> 
>   I cannot convince myself it is right. How do you convince yourself?"
> 
> And you at that time claimed it was all fairly simple and clear.

I know, and I was pretty much expecting you to bring that up...

> I repeat: that whole apoll thing is disgusting. It wasn't simple and
> clear and only a few obvious cases that had issues.
> 
> In fact, now it's even less clear, with an even more complicated check
> for when to restore things,
> 
> I think that whole approach needs re-thinking. Is the union really worth it?
> 
> Can you guarantee and explain why _this_ time it is right?

To be fair, this place is really the only place that is a bit tricky, since
it's where we restore things. The rest is clear, since we know exactly
which poll (&req->poll, or req->apoll) that is being used. The fix from
last week ended up somewhat conflicting with the cancellation part, which
is part of the reason it slipped.

But I do hear your point. If we run into anything like this again, I'll
bite the bullet and un-unionize this thing. I just care pretty deeply
about keeping the footprint of a single io_uring request down to as
little as we can, as we can be doing millions of these (per core). We've
still got some room in terms of not spilling into the next cacheline.

-- 
Jens Axboe