Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934172AbdDGRlT (ORCPT ); Fri, 7 Apr 2017 13:41:19 -0400 Received: from g9t1613g.houston.hpe.com ([15.241.32.99]:49182 "EHLO g9t1613g.houston.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752130AbdDGRlK (ORCPT ); Fri, 7 Apr 2017 13:41:10 -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] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions Thread-Topic: [PATCH] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions Thread-Index: AQHSrxlon8WSkdMmSUCMHmfNPy80F6G6Lf+A Date: Fri, 7 Apr 2017 17:41:02 +0000 Message-ID: <1491586851.9118.33.camel@hpe.com> References: <149151227310.16957.8527168777601554707.stgit@dwillia2-desk3.amr.corp.intel.com> In-Reply-To: <149151227310.16957.8527168777601554707.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:PAE9qzcgxzxrkgO3bVVDE82jOSvudquztQ7RB8bbkZP2mrsXzfF43k8k5BiN2RHB28LS9MGPaprAt7T3m+1Tw4g/1ChebbclI/QXtAx+aj7XScebmlW1JsHSaE/jnVsrQDF2gAV2TH4WUVitpw0UC+M9IMxqKMTXYYncLC19nNwedhfOh65f7YsFdpjRuUyFhoZz8R6pwB8RI2pQ2ic4Loar3opwvqRFbRTaQBqD7PiJOP5c9wGhhp2wD9KM+Zwu9mpgHnnCmWm3/moiwScuKlG1+wufV/G5E1kStvlJHI8AiHVqJwNnZIRJsVzK2Ns3Pt99OjDr/rmLHASk7q1iqQ== x-ms-office365-filtering-correlation-id: bae33a2e-6dba-4680-bb01-08d47ddd429f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);SRVR:CS1PR84MB0293; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(6072148);SRVR:CS1PR84MB0293;BCL:0;PCL:0;RULEID:;SRVR:CS1PR84MB0293; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39400400002)(39450400003)(39860400002)(39840400002)(39410400002)(39850400002)(24454002)(377424004)(86362001)(5660300001)(38730400002)(4326008)(7416002)(2900100001)(36756003)(25786009)(54356999)(50986999)(76176999)(66066001)(77096006)(6486002)(6506006)(33646002)(3280700002)(122556002)(6436002)(7736002)(305945005)(6512007)(53936002)(103116003)(189998001)(3660700001)(8666007)(6246003)(2950100002)(8676002)(8936002)(81166006)(229853002)(102836003)(6116002)(3846002)(2906002)(2501003);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: <9456DD8261A94D4E9A2F52DF52AD03DF@NAMPRD84.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2017 17:41:02.3059 (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 v37HfPct002041 Content-Length: 879 Lines: 19 On Thu, 2017-04-06 at 13:59 -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. The change looks good to me. Should we also avoid cache flushing in the case of size=4B & dest aligned by 4B? Thanks, -Toshi