Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp4132530pxk; Tue, 29 Sep 2020 15:34:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwWo5v9/SvPZWkfkgOOZrAD9r0LQuZv/wu3mLat4fEAAM/wlYG/SlpH3+UxNGnZXzCMbkC1 X-Received: by 2002:a17:906:488d:: with SMTP id v13mr6053929ejq.524.1601418876520; Tue, 29 Sep 2020 15:34:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601418876; cv=none; d=google.com; s=arc-20160816; b=SFqPEQ/RHZXn3/gO+FI1YlCPzbmuFQ0VQFePJGvM94nWXg2ayp9fyg/Tt0n53QwbH5 CX+424afqjqWzlMNEe0Bn0tkCEWodLqefzJg6RlnRG1chcPV9oEVMpdueHhUHPFsNmij /zZfsqV7P/slq+pFPObHARaqVnYt7hsn2NGfxLXoRKbEySmW8bosZLDWcSTIZXQ0DQeB VCCK/Qe4YwcEZ4IQvgjSVAQPMP/zc9YH5s8+NhoX5uwaGJBu0zrJWLddAgWRgM/PbNFn K8KcplbeH/XL7BCyrxS/nwdVncdJfi2/8smiID36lUkBs03xKjAjYwjkBCe4q8Tl5RGB 2GWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=QPj2R3F4bxqgWuYiH34pQvZpv0RaH6NFTUkbHCW2p24=; b=vpS2KiqR7rHyxY1wtXoEDF5hd/byWr/uFGIsV2b+XO78US1LJRsl64hY4mmXjUVVOE GM4hyBGdBwy1P65vFJrjFL8osgBXl9+5WkoblcwjF3IZ/YopevQQyoNW6DgISunZkmg0 QrKiywzl03yQrB6ahJGuPzMU8QqYQdA8zXzqLa64YXbt756H/h7kbWU57yDqlyXfWvPo J249QLiGDprpAitS3sVSF6/fDqE9VR0xCEIGxKJ9gdkPesjDs5srNIlIbOUaUeN3nxV9 melP0pXXZ/mdW7jPsTIuJfQVgqGgxadGY5j6fTPkFTiBwSTrglkyyWZ359YnzcwZrE8C CbcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=dlbxcu6T; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m12si1460141ejj.328.2020.09.29.15.34.13; Tue, 29 Sep 2020 15:34:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=dlbxcu6T; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728756AbgI2WcU (ORCPT + 99 others); Tue, 29 Sep 2020 18:32:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55426 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728206AbgI2WcU (ORCPT ); Tue, 29 Sep 2020 18:32:20 -0400 Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D2C71C061755 for ; Tue, 29 Sep 2020 15:32:19 -0700 (PDT) Received: by mail-ej1-x643.google.com with SMTP id p9so17805519ejf.6 for ; Tue, 29 Sep 2020 15:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QPj2R3F4bxqgWuYiH34pQvZpv0RaH6NFTUkbHCW2p24=; b=dlbxcu6TRRkiu15Lu8VAqKieaUpIrOtrMwMHoWuctx5bXT47yPVoIb2AYEVj6he4/p Vhi6jdQ09t8NtO7qV+ACUkt6R5KVg0ZLeemzdtWl8RPPfGqROOrFjR8f7XzWBqY3QYwZ VGcpngSn4fNVmQRiYp875EXhhC36oTIbb4BP4vBJFwrFFHZMKkcg0oW+hh42925gA1It /yusSQS+FDrByoROPjy4Tf4Y6ir+dOqZlTeMJG0f8zvZ+4W0ybAJ3t7+VAig/qZ27p0H NHTmwgcOomfZfulx1lWf74NiIjVVXUuGHZv0vLy8YXEdPZ+0QedQSMQO3PNJAhvdmo2w mvNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QPj2R3F4bxqgWuYiH34pQvZpv0RaH6NFTUkbHCW2p24=; b=P+ksO2p5yV6b0tgMzbJ/Ws3B9MOLk3hfZxe5N/wB/3/mCV51e6dOl/exA+SvrZyATz P5lEAivvJ0+UXNj4UFiNk83VY/odEuekkUcKQdHODgYkiwXGJ6cWfeWrzqxrHodAzuTx mz1pwfHJGujfTfh+xI/Dx87r3a7niaAkZsU+bm7ijxRmPH3SieVK3ZlAbemZl9OVuSQh K85ke9qCxPOkvpD9yPl9wXiQmIwdEdPiMOcCtK4vDagoHDdMJ99XJ/qAm0TArXotlzLQ EFySRe2D0yOGyshgeM196UUApPx1PaL6Ydz2wJMCbMP8Brohok7Yyg2K9LSzU7vkIylX COpQ== X-Gm-Message-State: AOAM531gC8m+EPorSoVrKHkMJjVasXYGNHFM3YabweMBKTQJ0azNy33V BY6iy2x7zJBiO7u5rBqxilkk89/GCZzyh+S7Fkv0GA== X-Received: by 2002:a17:906:8143:: with SMTP id z3mr5966464ejw.323.1601418738476; Tue, 29 Sep 2020 15:32:18 -0700 (PDT) MIME-Version: 1.0 References: <160087928642.3520.17063139768910633998.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: <160087928642.3520.17063139768910633998.stgit@dwillia2-desk3.amr.corp.intel.com> From: Dan Williams Date: Tue, 29 Sep 2020 15:32:07 -0700 Message-ID: Subject: Re: [PATCH v9 0/2] Renovate memcpy_mcsafe with copy_mc_to_{user, kernel} To: Ingo Molnar Cc: Tony Luck , Peter Zijlstra , Linus Torvalds , Alexander Viro , Borislav Petkov , stable , X86 ML , "H. Peter Anvin" , Thomas Gleixner , Andy Lutomirski , Paul Mackerras , Benjamin Herrenschmidt , Erwin Tsaur , Michael Ellerman , Mikulas Patocka , Arnaldo Carvalho de Melo , 0day robot , linux-nvdimm , Linux Kernel Mailing List , Jan Kara Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 23, 2020 at 10:00 AM Dan Williams wrote: > > Changes since v8 [1]: > - Rebase on v5.9-rc6 > > - Fix a performance regression in the x86 copy_mc_to_user() > implementation that was duplicating copies in the "fragile" case. > > - Refreshed the cover letter. > > [1]: http://lore.kernel.org/r/159630255616.3143511.18110575960499749012.stgit@dwillia2-desk3.amr.corp.intel.com > Given that Linus was the primary source of review feedback on these patches and a version of them have been soaking in -next with only a minor conflict report with vfs.git for the entirety of the v5.9-rc cycle (left there inadvertently while I was on leave), any concerns with me sending this to Linus directly during the merge window? > > The motivations to go rework memcpy_mcsafe() are that the benefit of > doing slow and careful copies is obviated on newer CPUs, and that the > current opt-in list of cpus to instrument recovery is broken relative to > those cpus. There is no need to keep an opt-in list up to date on an > ongoing basis if pmem/dax operations are instrumented for recovery by > default. With recovery enabled by default the old "mcsafe_key" opt-in to > careful copying can be made a "fragile" opt-out. Where the "fragile" > list takes steps to not consume poison across cachelines. > > The discussion with Linus made clear that the current "_mcsafe" suffix > was imprecise to a fault. The operations that are needed by pmem/dax are > to copy from a source address that might throw #MC to a destination that > may write-fault, if it is a user page. So copy_to_user_mcsafe() becomes > copy_mc_to_user() to indicate the separate precautions taken on source > and destination. copy_mc_to_kernel() is introduced as a version that > does not expect write-faults on the destination, but is still prepared > to abort with an error code upon taking #MC. > > These patches have received a kbuild-robot build success notification > across 114 configs, the rebase to v5.9-rc6 did not encounter any > conflicts, and the merge with tip/master is conflict-free. > > --- > > Dan Williams (2): > x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user,kernel}() > x86/copy_mc: Introduce copy_mc_generic() > > > arch/powerpc/Kconfig | 2 > arch/powerpc/include/asm/string.h | 2 > arch/powerpc/include/asm/uaccess.h | 40 +++-- > arch/powerpc/lib/Makefile | 2 > arch/powerpc/lib/copy_mc_64.S | 4 > arch/x86/Kconfig | 2 > arch/x86/Kconfig.debug | 2 > arch/x86/include/asm/copy_mc_test.h | 75 +++++++++ > arch/x86/include/asm/mcsafe_test.h | 75 --------- > arch/x86/include/asm/string_64.h | 32 ---- > arch/x86/include/asm/uaccess.h | 21 +++ > arch/x86/include/asm/uaccess_64.h | 20 -- > arch/x86/kernel/cpu/mce/core.c | 8 - > arch/x86/kernel/quirks.c | 9 - > arch/x86/lib/Makefile | 1 > arch/x86/lib/copy_mc.c | 65 ++++++++ > arch/x86/lib/copy_mc_64.S | 165 ++++++++++++++++++++ > arch/x86/lib/memcpy_64.S | 115 -------------- > arch/x86/lib/usercopy_64.c | 21 --- > drivers/md/dm-writecache.c | 15 +- > drivers/nvdimm/claim.c | 2 > drivers/nvdimm/pmem.c | 6 - > include/linux/string.h | 9 - > include/linux/uaccess.h | 9 + > include/linux/uio.h | 10 + > lib/Kconfig | 7 + > lib/iov_iter.c | 43 +++-- > tools/arch/x86/include/asm/mcsafe_test.h | 13 -- > tools/arch/x86/lib/memcpy_64.S | 115 -------------- > tools/objtool/check.c | 5 - > tools/perf/bench/Build | 1 > tools/perf/bench/mem-memcpy-x86-64-lib.c | 24 --- > tools/testing/nvdimm/test/nfit.c | 48 +++--- > .../testing/selftests/powerpc/copyloops/.gitignore | 2 > tools/testing/selftests/powerpc/copyloops/Makefile | 6 - > .../selftests/powerpc/copyloops/copy_mc_64.S | 1 > .../selftests/powerpc/copyloops/memcpy_mcsafe_64.S | 1 > 37 files changed, 452 insertions(+), 526 deletions(-) > rename arch/powerpc/lib/{memcpy_mcsafe_64.S => copy_mc_64.S} (98%) > create mode 100644 arch/x86/include/asm/copy_mc_test.h > delete mode 100644 arch/x86/include/asm/mcsafe_test.h > create mode 100644 arch/x86/lib/copy_mc.c > create mode 100644 arch/x86/lib/copy_mc_64.S > delete mode 100644 tools/arch/x86/include/asm/mcsafe_test.h > delete mode 100644 tools/perf/bench/mem-memcpy-x86-64-lib.c > create mode 120000 tools/testing/selftests/powerpc/copyloops/copy_mc_64.S > delete mode 120000 tools/testing/selftests/powerpc/copyloops/memcpy_mcsafe_64.S > > base-commit: ba4f184e126b751d1bffad5897f263108befc780 > _______________________________________________ > Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org > To unsubscribe send an email to linux-nvdimm-leave@lists.01.org