From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9FC68C282CB for ; Tue, 5 Feb 2019 19:30:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6C85B217D6 for ; Tue, 5 Feb 2019 19:30:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=amazonses.com header.i=@amazonses.com header.b="VVg9xA+D" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729343AbfBETaX (ORCPT ); Tue, 5 Feb 2019 14:30:23 -0500 Received: from a9-46.smtp-out.amazonses.com ([54.240.9.46]:36528 "EHLO a9-46.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727122AbfBETaX (ORCPT ); Tue, 5 Feb 2019 14:30:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1549395022; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:MIME-Version:Content-Type:Feedback-ID; bh=YJTd4VU+NL7d41BJd/g/275y6kyES9bTfQmjZG0ZH+I=; b=VVg9xA+DkL+JMOKCvFEIsD3XF1phH2CCO/7+guj4mnZ3H1lP6Pn4EiG7M3TNes+Q F+/9xWOc2jtDS9z+NpYZrsT3EvFzypd6UNaSuc8OcyeiKqsf8uP8RLqRn+5P+soDC2E o4/78BCE2H2py7WW36QP0n1XyVmiXR+H7uHrRwh4= Date: Tue, 5 Feb 2019 19:30:22 +0000 From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Ira Weiny 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 In-Reply-To: <20190204233513.GA7917@iweiny-DESK2.sc.intel.com> Message-ID: <01000168bf23d0fa-f96456c7-8569-4542-9926-f91baa3c0f06-000000@email.amazonses.com> References: <20190204052135.25784-1-jhubbard@nvidia.com> <01000168b980e880-a7d8e0db-84fb-4398-8269-149c66b701b4-000000@email.amazonses.com> <20190204233513.GA7917@iweiny-DESK2.sc.intel.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SES-Outgoing: 2019.02.05-54.240.9.46 Feedback-ID: 1.us-east-1.fQZZZ0Xtj2+TD7V5apTT/NrT6QKuPgzCT/IC7XYgDKI=:AmazonSES Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 4 Feb 2019, Ira Weiny wrote: > 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. DAX is a special file system that does not use writeback for the DAX mappings. Thus it could be an exception. And the pages are already pinned.