Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5043325imu; Wed, 19 Dec 2018 04:47:16 -0800 (PST) X-Google-Smtp-Source: AFSGD/Wg6dsYkWA/uyp40EvCisKffE2KDd9W+uMMDZf3USOCUtmcAWXdWTuiFFYJ8D6xLPejQFDq X-Received: by 2002:a62:7086:: with SMTP id l128mr20272638pfc.68.1545223636880; Wed, 19 Dec 2018 04:47:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545223636; cv=none; d=google.com; s=arc-20160816; b=DcE4x6CuLrWPICieKdNo6eEeiDGuHtXJNXnqvZLglny0nRoEnDlGp1N2g7aX8RFYwp PJF2RAyQ51stvVq2PxOMd+nENJLtjXakdQzdTakzM0DSPlkh3cqogCnDBaaAlNVeSzZp aBIm9gpJKz3jvz6JFIcYw6zoKFer9Jp7MO9dagHX0PZTEUW08LRYGNZBBTzS239bfAW3 JMrWamcszs5GwWM2+Y5VIly2qrbriusotTsoRzUzqqBSbPv/TOFRtj0NDYCsCJT6SkFl jUQqtdGbVQb5WtjgtpY2xUxpE8vOYOxuHkCibrNw+N5DM2MD1wWolEHf/cE6yXu7u/Q6 AVXw== 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=1GvQiqWWx745OEjLs7zKYNUkh8oD4KbMWdxz/8vvCoE=; b=L1n2kw8Cq+sOrMGBz7HUTdTO9GUUZbazTFlx8mKLJ15LGf2l4T5S8KC2Lr0UqU/COi sHT0VXUcj6Xt3L7EazblkpXA61qWOjRBQR655J2HM85IyWR2C3mcnBz6SfFjo6YEm+R0 Wt9rqQIvo7n/pKwupSA0APU7PLKqEpGDr+WSm4dWaft+C0vgh9A3Rj4yEz8eM2HrCsoO bYMgQRW0EwVRB+tCsRIq1IbvqxssOoy20u1a2g1ibb0rxbJAAiIG2oTVFH0ODwY8jAT6 m3ygMK2f6rUr3zvDUsbQfOicuSOI1lNoarSV6GxCR6xZUDbtMzIcOp8PXKSZBsouBBQ4 bUcw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s59si98913plb.350.2018.12.19.04.47.01; Wed, 19 Dec 2018 04:47:16 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728456AbeLSLfo (ORCPT + 99 others); Wed, 19 Dec 2018 06:35:44 -0500 Received: from mx2.suse.de ([195.135.220.15]:38322 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727111AbeLSLfo (ORCPT ); Wed, 19 Dec 2018 06:35:44 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 59555ACB5; Wed, 19 Dec 2018 11:35:42 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id DF6251E1463; Wed, 19 Dec 2018 12:35:40 +0100 (CET) Date: Wed, 19 Dec 2018 12:35:40 +0100 From: Jan Kara To: Dave Chinner Cc: Jason Gunthorpe , Jan Kara , Jerome Glisse , John Hubbard , Matthew Wilcox , Dan Williams , 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@intel.com, rcampbell@nvidia.com, Linux Kernel Mailing List , linux-fsdevel Subject: Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions Message-ID: <20181219113540.GC18345@quack2.suse.cz> References: <20181208022445.GA7024@redhat.com> <20181210102846.GC29289@quack2.suse.cz> <20181212150319.GA3432@redhat.com> <20181212214641.GB29416@dastard> <20181214154321.GF8896@quack2.suse.cz> <20181216215819.GC10644@dastard> <20181218103306.GC18032@quack2.suse.cz> <20181218234254.GC31274@dastard> <20181219030329.GI21992@ziepe.ca> <20181219102825.GN6311@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181219102825.GN6311@dastard> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 19-12-18 21:28:25, Dave Chinner wrote: > On Tue, Dec 18, 2018 at 08:03:29PM -0700, Jason Gunthorpe wrote: > > On Wed, Dec 19, 2018 at 10:42:54AM +1100, Dave Chinner wrote: > > > > > Essentially, what we are talking about is how to handle broken > > > hardware. I say we should just brun it with napalm and thermite > > > (i.e. taint the kernel with "unsupportable hardware") and force > > > wait_for_stable_page() to trigger when there are GUP mappings if > > > the underlying storage doesn't already require it. > > > > If you want to ban O_DIRECT/etc from writing to file backed pages, > > then just do it. > > O_DIRECT IO *isn't the problem*. That is not true. O_DIRECT IO is a problem. In some aspects it is easier than the problem with RDMA but currently O_DIRECT IO can crash your machine or corrupt data the same way RDMA can. Just the race window is much smaller. So we have to fix the generic GUP infrastructure to make O_DIRECT IO work. I agree that fixing RDMA will likely require even more work like revokable leases or what not. > iO_DIRECT IO uses a short term pin that the existing prefaulting > during GUP works just fine for. The problem we have is the long term > pins where pages can be cleaned while the pages are pinned. i.e. the > use case we current have to disable for DAX because *we can't make > it work sanely* without either revokable file leases and/or hardware > that is able to trigger page faults when they need write access to a > clean page. I would like to find a solution to the O_DIRECT IO problem while making the infractructure reusable also for solving the problems with RDMA... Because nobody wants to go through those couple hundred get_user_pages() users in the kernel twice... Honza -- Jan Kara SUSE Labs, CR