linux-kernel - Re: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput -16.9% regression

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:   Wed, 15 Nov 2023 13:38:18 -0500
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Howells <dhowells@...hat.com>, Borislav Petkov <bp@...en8.de>
Cc:     kernel test robot <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev,
        lkp@...el.com, linux-kernel@...r.kernel.org,
        Christian Brauner <brauner@...nel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Jens Axboe <axboe@...nel.dk>, Christoph Hellwig <hch@....de>,
        Christian Brauner <christian@...uner.io>,
        Matthew Wilcox <willy@...radead.org>,
        David Laight <David.Laight@...lab.com>, ying.huang@...el.com,
        feng.tang@...el.com, fengwei.yin@...el.com
Subject: Re: [linus:master] [iov_iter] c9eec08bac: vm-scalability.throughput
 -16.9% regression

On Wed, 15 Nov 2023 at 12:38, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> The gcc code generation here is *really* odd. I've never seen this
> before, so it may be new to newer versions of gcc. [...]

Ok, so I've been annoyed by gcc code generation for 'memcpy()' before,
mainly because it can't do the "let's inline it as an ALTERNATIVE() of
'rep movs' or an out-of-line call" thing that we do for user copies.

So here's a complete hack that says "we override the
__builtin_memcpy() implementation for non-constant lengths". We
stillwant gcc to deal with the constant size case, since often that
can be turned into just plain moves.

And this is *ENTIRELY* untested, except for checking that it makes the
code generation in lib/iov_iter.c look better.

It's probably completely broken. I particularly worry about "memcpy()"
being used *during* the instruction rewriting, so the whole approach
with ALTERNATIVE() is probably entirely broken.

But I'm cc'ing Borislav, because we've talked about the whole "inline
memcpy() with alternatives" before, so maybe this gives Borislav some
ideas for how to do it right.

Borislav, see

    https://lore.kernel.org/all/CAHk-=wjCUckvZUQf7gqp2ziJUWxVpikM_6srFdbcNdBJTxExRg@mail.gmail.com/

for some truly crazy code generation by gcc.

                   Linus

View attachment "patch.diff" of type "text/x-patch" (1897 bytes)