Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp241202imu; Wed, 12 Dec 2018 15:56:55 -0800 (PST) X-Google-Smtp-Source: AFSGD/X4eWFNptTwRL7DMeQC3ZtUWkNTICOBrlkVrkT7XGtWFjs5PQb49wXIRWCxym1egnMoaPsp X-Received: by 2002:a63:1204:: with SMTP id h4mr20026308pgl.51.1544659015776; Wed, 12 Dec 2018 15:56:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544659015; cv=none; d=google.com; s=arc-20160816; b=Ep1BVM+L3Mlw6XLt36lXL+/NK4S7WswYdRTX191X/ACxxwpRsb4T8gqY1TUAMLYUd6 zqoOH6R58B34ayLP3GFvV43NjiISHN4G1a8cl267HcN8fvFXT2xl/pDflNCByXrMz27j jq8tzlnMXkc1g0JQZ3L3qiF31mLAmrO5W5QUMLRIZxamOfTFImWEhJixszx9ark98gX4 1SlnmFnw70R6H4iuqac/rPgqLeKMDW1UA/OGvseD+fGb7eG8yoFPbC0/veqBG6SRxa1h yYugHPiHN0cnRpcSIWNSDTRjkz6rKyfMeMhDZn18+3v0gbc1IoSPSp7ZEW6CfwPzMdkA C+Wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=E7mdoMuLEW5kIzmk2Ogie0ESsqgQeSFFGnaWUn73X3g=; b=zAr60t9VXm45jV+Kr1Ge/0OKGSv1HlP/sjW97Q0J0232f4Z+qr+wv3oP4/bmoUEcG2 dnStPDKpB89DCRc2b8N7hMIO0blNAIZ92bRkE0eKr/7TLaM6V0eAxLUUor6Lm4hEdItl h/95qF2AdhGtc3dbCZKeYqiQDvj251e3wqD9hYH9y+AASXigJZg32/3oxmWKjxVdRtyP jpW/M2bOYbCBzqBAI5K4EOZHLoUFR7bYzcnmPDGk75q1G1SY+WK0aIaCNzJghgA2tlvJ zXxN+9nelHJfukwH1HSy7pzJigg4cSj4DzFqzr+pf41lmMT1kwjkcN8sGoK6gc/ieR3/ vJdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="JX1k8/Sx"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id h5si164156pgc.237.2018.12.12.15.56.41; Wed, 12 Dec 2018 15:56:55 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="JX1k8/Sx"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1728523AbeLLXyj (ORCPT + 99 others); Wed, 12 Dec 2018 18:54:39 -0500 Received: from mail-oi1-f194.google.com ([209.85.167.194]:40914 "EHLO mail-oi1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727003AbeLLXyi (ORCPT ); Wed, 12 Dec 2018 18:54:38 -0500 Received: by mail-oi1-f194.google.com with SMTP id t204so181591oie.7 for ; Wed, 12 Dec 2018 15:54:38 -0800 (PST) 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=E7mdoMuLEW5kIzmk2Ogie0ESsqgQeSFFGnaWUn73X3g=; b=JX1k8/SxOV8BTY3/m5T31tYgCrZHhX6a03J8tdt1G+5VkrRdSkL0PNtmbjPxd7VFGx alzEU/BHPWk785sT65M9yCqJht00/uFb7l5+xac3/VE+tF3RGHiwrSTFN2W9E9oFPzvp 5v76FOVbvtC/TTXWzrygTVBGsSZhWolmWVOZ3DkzF1JfzGbOFeYkhlVrfb5i9fSsikZC WCpGaJbJnwdv5x4pm122v1RKW8liAy2KxWWEu0FDAcCnYBsqNfQbXGHhk7NFoyfFHvqN Aor1h3nMXwpo3lh5SAAOe/b32Wbts7dmspyNa338KfFi3zocz08h3JT0HJ7Ro2yBcaBk RQQA== 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=E7mdoMuLEW5kIzmk2Ogie0ESsqgQeSFFGnaWUn73X3g=; b=BIz23fQ69VCchSQBCT1hy7lTvTdQ+MHfEGmOk7Qx0zth1yO+n5oU3Z3aYScqPEgw2h By50IJ3tsGY5g+srco4UUR/pq3E/ZkTZYFUmSKfBWMUtxRJ1udd0sRKAi0YGEsRJxgo3 FhdAALsyXbJOKGriyV4afWmdjg/LJb10bisQSWSX+5eXe2uPiIkL9epoWV6NTPD9akKR hFjVuy5FuVvjFv0dIjJqS8W4JWpPojzgrq/przPtbW1DzDUfD0Ke5kBvsJP8bNU7DJx0 kEjMZeSPSZNZZiORN0/GKe8Xoln15Px1X5DvlYg/TwuKYJPLr5BjJDl4s0REjjW1vmCt Jb/A== X-Gm-Message-State: AA+aEWYTxaA/PlQ5pULH1lKoZGmZHPyyMnG6jh6h+px7b5a/HQ9CdwQv 4+bMRTxAf2TQQ/TXeqJOGahH8LCzQSqZTgKcUxLQZg== X-Received: by 2002:aca:d78b:: with SMTP id o133mr1551320oig.232.1544658877677; Wed, 12 Dec 2018 15:54:37 -0800 (PST) MIME-Version: 1.0 References: <7b4733be-13d3-c790-ff1b-ac51b505e9a6@nvidia.com> <20181207191620.GD3293@redhat.com> <3c4d46c0-aced-f96f-1bf3-725d02f11b60@nvidia.com> <20181208022445.GA7024@redhat.com> <20181210102846.GC29289@quack2.suse.cz> <20181212150319.GA3432@redhat.com> <20181212213005.GE5037@redhat.com> <20181212215348.GF5037@redhat.com> <20181212233703.GB2947@ziepe.ca> In-Reply-To: <20181212233703.GB2947@ziepe.ca> From: Dan Williams Date: Wed, 12 Dec 2018 15:54:26 -0800 Message-ID: Subject: Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions To: Jason Gunthorpe Cc: =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , Jan Kara , John Hubbard , Matthew Wilcox , John Hubbard , Andrew Morton , Linux MM , tom@talpey.com, Al Viro , benve@cisco.com, Christoph Hellwig , Christopher Lameter , "Dalessandro, Dennis" , Doug Ledford , Michal Hocko , Mike Marciniszyn , rcampbell@nvidia.com, Linux Kernel Mailing List , linux-fsdevel , "Weiny, Ira" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 12, 2018 at 3:37 PM Jason Gunthorpe wrote: > > On Wed, Dec 12, 2018 at 04:53:49PM -0500, Jerome Glisse wrote: > > > Almost, we need some safety around assuming that DMA is complete the > > > page, so the notification would need to go all to way to userspace > > > with something like a file lease notification. It would also need to > > > be backstopped by an IOMMU in the case where the hardware does not / > > > can not stop in-flight DMA. > > > > You can always reprogram the hardware right away it will redirect > > any dma to the crappy page. > > That causes silent data corruption for RDMA users - we can't do that. > > The only way out for current hardware is to forcibly terminate the > RDMA activity somehow (and I'm not even sure this is possible, at > least it would be driver specific) > > Even the IOMMU idea probably doesn't work, I doubt all current > hardware can handle a PCI-E error TLP properly. My thinking here is that we would at least have the infrastructure for userspace to opt-in to getting the callback, the threat of an IOMMU forcibly tearing down mappings, and likely some identification for pages that are revocable. With "long term" pins I would hope to move any detection of incompatibility to the memory registration phase rather than something unacceptable like injecting random truncate failures.