[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cab741e4-8434-6e0c-4b05-f6033adbefd2@deltatee.com>
Date: Sat, 4 Mar 2017 21:58:14 -0700
From: Logan Gunthorpe <logang@...tatee.com>
To: Borislav Petkov <bp@...e.de>, hpa@...or.com
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Tony Luck <tony.luck@...el.com>,
Al Viro <viro@...iv.linux.org.uk>,
the arch/x86 maintainers <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Question Regarding ERMS memcpy
Hey,
On 04/03/17 05:33 PM, Borislav Petkov wrote:
> On Sat, Mar 04, 2017 at 04:23:17PM -0800, hpa@...or.com wrote:
>> What are the compilation flags? It may be that gcc still does TRT
>> depending on this call site. I'd check what gcc6 or 7 generates,
>> though.
> Hmm, I wish we were able to say, "let gcc decide for small sizes and let
> us do the patching for larger ones."
So, I've found that my kernel config had the OPTIMIZE_FOR_SIZE selected
instead of OPTIMIZE_FOR_PERFORMANCE. I'm not sure why that is but
switching to the latter option fixes my problem. A memcpy call is used
instead of the poor inline solution. (I'm not really sure how the inline
solution even makes any sense as it almost certainly makes things larger
in the grand scheme of things.)
It still might make sense to apply your patch asking gcc to never use
the broken memcpy but I'll leave that in your capable hands to decide.
Anyway, thanks for the help with this.
Logan
Powered by blists - more mailing lists