Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1592649
| From | Borislav Petkov <bp@suse.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Question Regarding ERMS memcpy |
| Date | 2017-03-05 01:20 +0100 |
| Message-ID | <ths41-gf-3@gated-at.bofh.it> (permalink) |
| References | <thpfP-6Lj-13@gated-at.bofh.it> <thqEV-7AQ-5@gated-at.bofh.it> <thrKF-8kZ-13@gated-at.bofh.it> <thrKF-8kZ-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Sat, Mar 04, 2017 at 03:55:27PM -0800, hpa@zytor.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)
--
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Question Regarding ERMS memcpy Logan Gunthorpe <logang@deltatee.com> - 2017-03-04 22:20 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-04 23:50 +0100
Re: Question Regarding ERMS memcpy hpa@zytor.com - 2017-03-05 01:00 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 01:20 +0100
Re: Question Regarding ERMS memcpy hpa@zytor.com - 2017-03-05 01:30 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 01:40 +0100
Re: Question Regarding ERMS memcpy hpa@zytor.com - 2017-03-05 02:00 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 11:00 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 12:20 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 14:10 +0100
Re: Question Regarding ERMS memcpy Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-05 20:30 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 21:20 +0100
Re: Question Regarding ERMS memcpy Linus Torvalds <torvalds@linux-foundation.org> - 2017-03-05 21:20 +0100
Re: Question Regarding ERMS memcpy Logan Gunthorpe <logang@deltatee.com> - 2017-03-06 08:10 +0100
Re: Question Regarding ERMS memcpy "H. Peter Anvin" <hpa@zytor.com> - 2017-03-06 08:40 +0100
Re: Question Regarding ERMS memcpy Logan Gunthorpe <logang@deltatee.com> - 2017-03-06 18:50 +0100
Re: Question Regarding ERMS memcpy hpa@zytor.com - 2017-03-06 20:10 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-06 14:40 +0100
Re: Question Regarding ERMS memcpy hpa@zytor.com - 2017-03-06 14:50 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-06 15:10 +0100
Re: Question Regarding ERMS memcpy Logan Gunthorpe <logang@deltatee.com> - 2017-03-05 06:00 +0100
Re: Question Regarding ERMS memcpy Borislav Petkov <bp@suse.de> - 2017-03-05 11:00 +0100
csiph-web