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]

Date:   Sat, 9 Jan 2021 21:49:27 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Al Viro' <viro@...iv.linux.org.uk>,
        Pavel Begunkov <asml.silence@...il.com>
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

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.

> 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.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)