Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753389AbdDKPP0 (ORCPT ); Tue, 11 Apr 2017 11:15:26 -0400 Received: from g2t1383g.austin.hpe.com ([15.233.16.89]:16913 "EHLO g2t1383g.austin.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751997AbdDKPPX (ORCPT ); Tue, 11 Apr 2017 11:15:23 -0400 From: "Kani, Toshimitsu" To: "dan.j.williams@intel.com" , "linux-nvdimm@lists.01.org" CC: "linux-kernel@vger.kernel.org" , "jmoyer@redhat.com" , "tglx@linutronix.de" , "hch@lst.de" , "stable@vger.kernel.org" , "viro@zeniv.linux.org.uk" , "x86@kernel.org" , "mawilcox@microsoft.com" , "hpa@zytor.com" , "mingo@redhat.com" , "ross.zwisler@linux.intel.com" , "jack@suse.cz" Subject: Re: [PATCH v3] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions Thread-Topic: [PATCH v3] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions Thread-Index: AQHSslxNtw08IaE0m0aQhkpSPGZOjqHASA6A Date: Tue, 11 Apr 2017 15:15:16 +0000 Message-ID: <1491923701.9118.34.camel@hpe.com> References: <149187075199.40875.9829505688202257056.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: <149187075199.40875.9829505688202257056.stgit@dwillia2-desk3.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=hpe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [15.219.163.8] x-microsoft-exchange-diagnostics: 1;CS1PR84MB0293;7:MhnA+Z4lNUkXO1P8ZyCgP5eGqHCCTJzHn9WcTLwQV6VBnIivEJwpNJ3yX0s4/F3AxVW9D0XvTX60RwpEYTs7RcLWMh/xMAOJU0sfsxtTDVZXUyM0syJ31toMoDhu2Ug/QjMAvHv+S0ZRfg/0rHGrJcCH7VoZ2AgTTlA5onXGvRQE6TBD+HobMyOxCbcz5ZBIxN6/CaYPOerG27BeVbXKmJcV0OF1ASDpGFO50Mu0otR3g5bLn3z6YvY5082R/ruFzkN+NCsj01xq3G/M5kygKMYI3qxa11KW7k6EZAal9zztqOBnHMYm5LPHBCjRP57YfDv9THwR6PTQExA5+ONz7Q== x-ms-office365-filtering-correlation-id: 3abc8b8c-d844-45e6-e4be-08d480ed8f2d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075);SRVR:CS1PR84MB0293; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861)(9452136761055)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148);SRVR:CS1PR84MB0293;BCL:0;PCL:0;RULEID:;SRVR:CS1PR84MB0293; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39400400002)(39850400002)(39410400002)(39840400002)(39860400002)(39450400003)(377424004)(24454002)(6436002)(77096006)(6486002)(33646002)(6506006)(2950100002)(229853002)(8666007)(6512007)(8676002)(8936002)(6246003)(25786009)(103116003)(3660700001)(102836003)(2501003)(2906002)(6116002)(3280700002)(3846002)(81166006)(86362001)(2900100001)(53936002)(5660300001)(38730400002)(36756003)(7736002)(50986999)(305945005)(76176999)(189998001)(54356999)(7416002)(122556002)(66066001)(4326008);DIR:OUT;SFP:1102;SCL:1;SRVR:CS1PR84MB0293;H:CS1PR84MB0294.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <811AD640C00A03489F50834542E5B8AF@NAMPRD84.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2017 15:15:16.1564 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR84MB0293 X-OriginatorOrg: hpe.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v3BFFU1r025367 Content-Length: 1647 Lines: 40 On Mon, 2017-04-10 at 17:35 -0700, Dan Williams wrote: > Before we rework the "pmem api" to stop abusing __copy_user_nocache() > for memcpy_to_pmem() we need to fix cases where we may strand dirty > data in the cpu cache. The problem occurs when copy_from_iter_pmem() > is used for arbitrary data transfers from userspace. There is no > guarantee that these transfers, performed by dax_iomap_actor(), will > have aligned destinations or aligned transfer lengths. Backstop the > usage __copy_user_nocache() with explicit cache management in these > unaligned cases. > > Yes, copy_from_iter_pmem() is now too big for an inline, but > addressing that is saved for a later patch that moves the entirety of > the "pmem api" into the pmem driver directly. > > Fixes: 5de490daec8b ("pmem: add copy_from_iter_pmem() and > clear_pmem()") > Cc: > Cc: > Cc: Jan Kara > Cc: Jeff Moyer > Cc: Ingo Molnar > Cc: Christoph Hellwig > Cc: "H. Peter Anvin" > Cc: Al Viro > Cc: Thomas Gleixner > Cc: Matthew Wilcox > Cc: Ross Zwisler > Signed-off-by: Toshi Kani > Signed-off-by: Dan Williams > --- > Changes in v3: > * match the implementation to the notes at the top of >   __copy_user_nocache (Toshi) > > * Switch to using the IS_ALIGNED() macro to make alignment checks > easier to read and harder to get wrong like they were in v2. (Toshi, > Dan) Thanks Dan! It looks good. -Toshi