linux-kernel - Re: [PATCH] iov_iter: optimise iter type checking

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: <1783c58f-1016-0c6b-be7f-a93bc2f8f2a4@gmail.com>
Date:   Sat, 9 Jan 2021 22:11:09 +0000
From:   Pavel Begunkov <asml.silence@...il.com>
To:     David Laight <David.Laight@...LAB.COM>,
        'Al Viro' <viro@...iv.linux.org.uk>
Cc:     "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        Jens Axboe <axboe@...nel.dk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] iov_iter: optimise iter type checking

On 09/01/2021 21:49, David Laight wrote:
> From: Al Viro
>> Sent: 09 January 2021 17:04
>>
>> On Sat, Jan 09, 2021 at 04:09:08PM +0000, Pavel Begunkov wrote:
>>> On 06/12/2020 16:01, Pavel Begunkov wrote:
>>>> On 21/11/2020 14:37, Pavel Begunkov wrote:
>>>>> The problem here is that iov_iter_is_*() helpers check types for
>>>>> equality, but all iterate_* helpers do bitwise ands. This confuses
>>>>> compilers, so even if some cases were handled separately with
>>>>> iov_iter_is_*(), corresponding ifs in iterate*() right after are not
>>>>> eliminated.
>>>>>
>>>>> E.g. iov_iter_npages() first handles discards, but iterate_all_kinds()
>>>>> still checks for discard iter type and generates unreachable code down
>>>>> the line.
>>>>
>>>> Ping. This one should be pretty simple
>>>
>>> Ping please. Any doubts about this patch?
>>
>> Sorry, had been buried in other crap.  I'm really not fond of the
>> bitmap use; if anything, I would rather turn iterate_and_advance() et.al.
>> into switches...
> 
> That loses any optimisations in the order of the comparisons.
> The bitmap also allows different groups to be optimised for in different code paths.

You still can have a fast path and even retoss ITER_* for convenience.
Other use cases are not important at the current state.

> 
>> How about moving the READ/WRITE part into MSB?  Checking is just as fast
>> (if not faster - check for sign vs. checking bit 0).  And turn the
>> types into straight (dense) enum.
> 
> Does any code actually look at the fields as a pair?
> Would it even be better to use separate bytes?
> Even growing the on-stack structure by a word won't really matter.

u8 type, rw;

That won't bloat the struct. I like the idea. If used together compilers
can treat it as u16.

btw there is a 4B hole just after for x64.

-- 
Pavel Begunkov