Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp4377630ima; Mon, 4 Feb 2019 15:35:57 -0800 (PST) X-Google-Smtp-Source: AHgI3IaC3gVKdoPSwfA4upwYYoY+XP1xg61mR1mIK7ejx636J0TMFffGg2PGw+nOu3whKRe1fyS2 X-Received: by 2002:a17:902:4124:: with SMTP id e33mr1237808pld.236.1549323357680; Mon, 04 Feb 2019 15:35:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549323357; cv=none; d=google.com; s=arc-20160816; b=zBVPGKaye7DmSMjytbFk3M4pWJp726IG053t4jjQKs8PpAjI22iI/eUYZ3+vi47MUW YZ5pxQixppR1RutmkPSk2RibiCRM/QTnCLeTuqCZHpgEaKlPizsDBPOvCVjFSGme3ZjM K4Ia85ADwj8gKnsDgncodpf2lmt0VzhAAS7qRsW/tA0K5TBjDWMp+w9Q/iRlGnS05/1o Sz3KKqANexab44/o9Gwg1RqbTQIjn7Jv35KSTYpEkFS2AcLJhdRXLZjavIpsHG/TC6om CoOAtp38IyxmyQgHHZQyckV+pYtvrvZRwEzrPxE8kiLUT0s7RqaKULtPs7zwDTtjTY33 a8eA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=wtuXUqV4ZOFvc0OvGpbjmwczJBBbXCS+25V52I6nESg=; b=bxsJQdv3GX1ditIUa7InP/ZW6ljsN2evzQSSV13uFDSUtbP3+d0YpAUBJveKyG/PBP +dgNxYIq3kq3t90i8AXXkGFSfWiP8Q+no7nbt5SP+qNAVl/caaIdpEnyIbqU6r/BJjLO A95JHtAXXIfzfhB+z7cqjmf+BmoKFNqDXbWtc8/m6Ol9EqhanoBbRTa2OAZg8BbBqprX ufsi461zuW+kZdOWAW35CXDXaTyGcpHGv7XxfzvR4tiTgIyVXSpia3J6Skm5f7yzCNXn 0qV6+Xyx/vjryzDa2s1aOkeDudsvKpAU+ro5ZoCttjKXIwZoK2Zz9uKvUiyuaOV31ARE ZEgw== ARC-Authentication-Results: i=1; mx.google.com; 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 m3si1263763pgc.232.2019.02.04.15.35.41; Mon, 04 Feb 2019 15:35:57 -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; 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 S1726978AbfBDXfg (ORCPT + 99 others); Mon, 4 Feb 2019 18:35:36 -0500 Received: from mga06.intel.com ([134.134.136.31]:59687 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726083AbfBDXff (ORCPT ); Mon, 4 Feb 2019 18:35:35 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2019 15:35:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,560,1539673200"; d="scan'208";a="113707140" Received: from iweiny-desk2.sc.intel.com ([10.3.52.157]) by orsmga006.jf.intel.com with ESMTP; 04 Feb 2019 15:35:34 -0800 Date: Mon, 4 Feb 2019 15:35:14 -0800 From: Ira Weiny To: Christopher Lameter Cc: john.hubbard@gmail.com, Andrew Morton , linux-mm@kvack.org, Al Viro , Christian Benvenuti , Christoph Hellwig , Dan Williams , Dave Chinner , Dennis Dalessandro , Doug Ledford , Jan Kara , Jason Gunthorpe , Jerome Glisse , Matthew Wilcox , Michal Hocko , Mike Rapoport , Mike Marciniszyn , Ralph Campbell , Tom Talpey , LKML , linux-fsdevel@vger.kernel.org, John Hubbard Subject: Re: [PATCH 0/6] RFC v2: mm: gup/dma tracking Message-ID: <20190204233513.GA7917@iweiny-DESK2.sc.intel.com> References: <20190204052135.25784-1-jhubbard@nvidia.com> <01000168b980e880-a7d8e0db-84fb-4398-8269-149c66b701b4-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01000168b980e880-a7d8e0db-84fb-4398-8269-149c66b701b4-000000@email.amazonses.com> User-Agent: Mutt/1.11.1 (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 04, 2019 at 05:14:19PM +0000, Christopher Lameter wrote: > Frankly I still think this does not solve anything. > > Concurrent write access from two sources to a single page is simply wrong. > You cannot make this right by allowing long term RDMA pins in a filesystem > and thus the filesystem can never update part of its files on disk. > > Can we just disable RDMA to regular filesystems? Regular filesystems > should have full control of the write back and dirty status of their > pages. That may be a solution to the corruption/crashes but it is not a solution which users want to see. RDMA directly to file systems (specifically DAX) is a use case we have seen customers ask for. I think this is the correct path toward supporting this use case. Ira