linux-kernel - Re: [PATCH 16/16] mm: pass get_user_pages_fast iterator arguments in a structure

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: <0441EC80-B09F-4722-B186-E42EB6A83386@gmail.com>
Date:   Tue, 11 Jun 2019 18:27:09 -0700
From:   Nadav Amit <nadav.amit@...il.com>
To:     Nicholas Piggin <npiggin@...il.com>, Christoph Hellwig <hch@....de>
Cc:     Rich Felker <dalias@...c.org>,
        "David S. Miller" <davem@...emloft.net>,
        James Hogan <jhogan@...nel.org>,
        Paul Burton <paul.burton@...s.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Khalid Aziz <khalid.aziz@...cle.com>,
        LKML <linux-kernel@...r.kernel.org>, linux-mips@...r.kernel.org,
        Linux-MM <linux-mm@...ck.org>, linuxppc-dev@...ts.ozlabs.org,
        linux-sh@...r.kernel.org, Michael Ellerman <mpe@...erman.id.au>,
        Paul Mackerras <paulus@...ba.org>, sparclinux@...r.kernel.org,
        the arch/x86 maintainers <x86@...nel.org>
Subject: Re: [PATCH 16/16] mm: pass get_user_pages_fast iterator arguments in
 a structure

> On Jun 11, 2019, at 5:52 PM, Nicholas Piggin <npiggin@...il.com> wrote:
> 
> Christoph Hellwig's on June 12, 2019 12:41 am:
>> Instead of passing a set of always repeated arguments down the
>> get_user_pages_fast iterators, create a struct gup_args to hold them and
>> pass that by reference.  This leads to an over 100 byte .text size
>> reduction for x86-64.
> 
> What does this do for performance? I've found this pattern can be
> bad for store aliasing detection.

Note that sometimes such an optimization can also have adverse effect due to
stack protector code that gcc emits when you use such structs.

Matthew Wilcox encountered such a case:
https://patchwork.kernel.org/patch/10702741/