Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752595AbdCEE60 (ORCPT ); Sat, 4 Mar 2017 23:58:26 -0500 Received: from ale.deltatee.com ([207.54.116.67]:41828 "EHLO ale.deltatee.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751554AbdCEE6Y (ORCPT ); Sat, 4 Mar 2017 23:58:24 -0500 To: Borislav Petkov , hpa@zytor.com References: <20170304224341.zfp4fl37ypt57amg@pd.tnic> <5CCEF10D-5647-4503-A398-0681DF2C8847@zytor.com> <20170305001447.kcxignj3nsq35vci@pd.tnic> <20170305003349.6kgq4ovj7ipezfxu@pd.tnic> Cc: Thomas Gleixner , Ingo Molnar , Tony Luck , Al Viro , the arch/x86 maintainers , Linux Kernel Mailing List From: Logan Gunthorpe Message-ID: Date: Sat, 4 Mar 2017 21:58:14 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170305003349.6kgq4ovj7ipezfxu@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 50.66.97.235 X-SA-Exim-Rcpt-To: linux-kernel@vger.kernel.org, x86@kernel.org, viro@zeniv.linux.org.uk, tony.luck@intel.com, mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com, bp@suse.de X-SA-Exim-Mail-From: logang@deltatee.com Subject: Re: Question Regarding ERMS memcpy X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on ale.deltatee.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 955 Lines: 23 Hey, On 04/03/17 05:33 PM, Borislav Petkov wrote: > On Sat, Mar 04, 2017 at 04:23:17PM -0800, hpa@zytor.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