Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752443AbdCEUTR (ORCPT ); Sun, 5 Mar 2017 15:19:17 -0500 Received: from mail-it0-f43.google.com ([209.85.214.43]:38154 "EHLO mail-it0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752296AbdCEUTQ (ORCPT ); Sun, 5 Mar 2017 15:19:16 -0500 MIME-Version: 1.0 In-Reply-To: <20170305195432.6occvwaujq3l4ejl@pd.tnic> References: <20170304224341.zfp4fl37ypt57amg@pd.tnic> <5CCEF10D-5647-4503-A398-0681DF2C8847@zytor.com> <20170305001447.kcxignj3nsq35vci@pd.tnic> <20170305003349.6kgq4ovj7ipezfxu@pd.tnic> <20170305095059.l4od2yjqm5yxx6ln@pd.tnic> <20170305195432.6occvwaujq3l4ejl@pd.tnic> From: Linus Torvalds Date: Sun, 5 Mar 2017 12:19:14 -0800 X-Google-Sender-Auth: PcS476tMp2b4XZx3jSC-pH9gAOQ Message-ID: Subject: Re: Question Regarding ERMS memcpy To: Borislav Petkov Cc: Logan Gunthorpe , Peter Anvin , Thomas Gleixner , Ingo Molnar , Tony Luck , Al Viro , "the arch/x86 maintainers" , Linux Kernel Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1812 Lines: 48 On Sun, Mar 5, 2017 at 11:54 AM, Borislav Petkov wrote: >> >> We seem to have broken this *really* long ago, though. > > I wonder why nothing blew up or failed strangely by now... The hardware that cared was pretty broken to begin with, and I think it was mainly some really odd graphics cards. And from memory, they had issues with 64-bit writes. We actually have a slow 16-bit word at a time copy for exactly these kinds of issues: scr_memcpyw() and friends. I'd like to say that it was one of those shit server-only cards that nobody sane would ever use (but "server hardware is validated and better quality!"), but that might have been another issue. >> For example, "rep movsb" really is the right thing to use on normal >> memory on modern CPU's. > > So Logan's box is a SNB and it doesn't have the ERMS optimizations. Are > you saying, regardless, we should let gcc put REP; MOVSB for smaller > sizes? I think gcc makes bad choices, but they are gcc';s choices to make. I have up on gcc's "-Os" because the choices were so bad and not getting fixed. .. and none of that has _anything_ to do with accesses to IO memory, which is fundamentally different. > Because gcc does generate a REP; MOVSB there when it puts its own > memcpy, see mail upthread. (Even though that is wrong to do on iomem.) No, *THAT* is not wrong to do on iomem. If we tell gcc that "memcpy()" works on iomem, then gcc can damn well do whatever it wants. "rep stosb" isn't wrong for memcpy(). Gcc may do stupid things with it, but that's completely immaterial. > Oh, and along with the revert we would need a big fat warning explaining > why we need that special memcpy for IO memory. Well, quite frankly, just a simple "IO memory is different from cached memory" should be sufficient. Linus