linux-kernel - Re: [GIT PULL] io_uring fix for 5.7-rc3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f903c9de-cec8-0a3e-efae-a3d37b6db4ad@kernel.dk>
Date:   Fri, 24 Apr 2020 14:11:54 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     io-uring <io-uring@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] io_uring fix for 5.7-rc3

On 4/24/20 2:03 PM, Linus Torvalds wrote:
> On Fri, Apr 24, 2020 at 11:03 AM Jens Axboe <axboe@...nel.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