[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170305001447.kcxignj3nsq35vci@pd.tnic>
Date: Sun, 5 Mar 2017 01:14:47 +0100
From: Borislav Petkov <bp@...e.de>
To: hpa@...or.com
Cc: Logan Gunthorpe <logang@...tatee.com>,
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
On Sat, Mar 04, 2017 at 03:55:27PM -0800, hpa@...or.com wrote:
> For newer processors, as determined by -mtune=, it is actually the
> best option for an arbitrary copy.
So his doesn't have ERMS - it is a SNB - so if for SNB REP_GOOD is
the best option for memcpy, then we should probably build with
-fno-builtin-memcpy unconditionally. Otherwise gcc apparently inserts
its own memcpy variant.
And this is probably wrong because we do the detection at boot time and
not at build time.
For example here it generates REP; MOVSL for the call in
drivers/firmware/dmi_scan.c::dmi_scan_machine() which looks wrong to me.
Length is 32 so it could just as well do REP; MOVSQ.
IOW, we could do something like this:
---
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 2d449337a360..c1b68d147b8d 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -142,10 +142,7 @@ ifdef CONFIG_X86_X32
endif
export CONFIG_X86_X32_ABI
-# Don't unroll struct assignments with kmemcheck enabled
-ifeq ($(CONFIG_KMEMCHECK),y)
- KBUILD_CFLAGS += $(call cc-option,-fno-builtin-memcpy)
-endif
+KBUILD_CFLAGS += $(call cc-option,-fno-builtin-memcpy)
# Stackpointer is addressed different for 32 bit and 64 bit x86
sp-$(CONFIG_X86_32) := esp
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
Powered by blists - more mailing lists