Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp1637584img;
        Tue, 19 Mar 2019 12:03:38 -0700 (PDT)
X-Google-Smtp-Source: APXvYqy6ShI2GRSk5umD7ihq2x25TW7FApIwx9D6X/p3PZQumb+Oh4AfAcHMCNlZ4H/br2mXZ5oW
X-Received: by 2002:a63:6883:: with SMTP id d125mr3736770pgc.324.1553022218196;
        Tue, 19 Mar 2019 12:03:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1553022218; cv=none;
        d=google.com; s=arc-20160816;
        b=u7kDM5u5xbGRQytlHDAdXB/IPVZbN2cTtAP0baaGB/Y5VPqRDP5G6d40rTwHLkb8Ui
         H0a+ZMbv6DNGJ8tGj7hwUwwqy6ywMzlKm0GQnrbC82xL/6dAQfAWfJonT/gu59lqcLBo
         a3kVgnEwXbPUlYnbi0LtFnG2BbL6lY37LDGMShskRcK7+bckEvkhS4Ihi7/DpxC359Q6
         ZyZi0PBkG/Q0ox1dDmcLb8ZpsxRKXn1+a2K9E7MoQEwnbHB9RUDkciAgL0lPGteUktBC
         VxZj0IxQKKCr8WlOlwj1HcOmiUgbcm7WqQnMisVZ/qfMf+IUaeoCXZjupRpRzW4p+ywI
         C3Pw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-id:precedence:sender:dkim-signature:content-transfer-encoding
         :content-language:in-reply-to:mime-version:user-agent:date
         :message-id:from:references:cc:to:subject;
        bh=NZoJbC8WOTr0NdLPHDxUPPIt9/DJYfgztYt8n26Np0U=;
        b=i2k3Proz2F7rAAOLT1nZagdqUI7Qxw21Bez4WEth5Qu/1z4PEz3rGQhzVRyE4ri5G8
         K3qrFyfpSlCZBJSIXCWeNs85Tn3mySa/qVFghpLqtGefkQ2OTCUpVEaM4FnQ7S3Ver9o
         CYLUnFkBUN0gTowcup3v+4h4Mb7trJK3jyTxWY3OPCPyzqqLgwxzdVDt66QXKNvPraUa
         ebBlikMSIei1dn4qIoaZ7lWsiMl8BQi5NE62K5CpsRUFVLlvn0tOBebez9EsdO+eJRKf
         EYI9hZ5mzBKQuYQn7oLNjufJwt/wErfBnXuOkvAxFipuOlKmlK/X6rzY8KoVnhmgLiX2
         f/xA==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@nvidia.com header.s=n1 header.b=cEUH3Lqw;
       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=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67])
        by mx.google.com with ESMTP id c22si12279803pls.17.2019.03.19.12.03.21;
        Tue, 19 Mar 2019 12:03:38 -0700 (PDT)
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=@nvidia.com header.s=n1 header.b=cEUH3Lqw;
       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=pass (p=NONE sp=NONE dis=NONE) header.from=nvidia.com
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1727177AbfCSTCf (ORCPT <rfc822;gklkml16@gmail.com> + 99 others);
        Tue, 19 Mar 2019 15:02:35 -0400
Received: from hqemgate15.nvidia.com ([216.228.121.64]:12311 "EHLO
        hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726939AbfCSTCf (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 19 Mar 2019 15:02:35 -0400
Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA)
        id <B5c913cb90000>; Tue, 19 Mar 2019 12:02:18 -0700
Received: from hqmail.nvidia.com ([172.20.161.6])
  by hqpgpgate102.nvidia.com (PGP Universal service);
  Tue, 19 Mar 2019 12:02:33 -0700
X-PGP-Universal: processed;
        by hqpgpgate102.nvidia.com on Tue, 19 Mar 2019 12:02:33 -0700
Received: from [10.110.48.28] (10.124.1.5) by HQMAIL101.nvidia.com
 (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar
 2019 19:02:32 +0000
Subject: Re: [PATCH v4 1/1] mm: introduce put_user_page*(), placeholder
 versions
To:     Jan Kara <jack@suse.cz>,
        "Kirill A. Shutemov" <kirill@shutemov.name>
CC:     Jerome Glisse <jglisse@redhat.com>, <john.hubbard@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        <linux-mm@kvack.org>, Al Viro <viro@zeniv.linux.org.uk>,
        Christian Benvenuti <benve@cisco.com>,
        Christoph Hellwig <hch@infradead.org>,
        Christopher Lameter <cl@linux.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Dave Chinner <david@fromorbit.com>,
        Dennis Dalessandro <dennis.dalessandro@intel.com>,
        Doug Ledford <dledford@redhat.com>,
        Ira Weiny <ira.weiny@intel.com>,
        Jason Gunthorpe <jgg@ziepe.ca>,
        Matthew Wilcox <willy@infradead.org>,
        Michal Hocko <mhocko@kernel.org>,
        Mike Rapoport <rppt@linux.ibm.com>,
        Mike Marciniszyn <mike.marciniszyn@intel.com>,
        Ralph Campbell <rcampbell@nvidia.com>,
        Tom Talpey <tom@talpey.com>,
        LKML <linux-kernel@vger.kernel.org>,
        <linux-fsdevel@vger.kernel.org>,
        Andrea Arcangeli <aarcange@redhat.com>
References: <20190308213633.28978-1-jhubbard@nvidia.com>
 <20190308213633.28978-2-jhubbard@nvidia.com>
 <20190319120417.yzormwjhaeuu7jpp@kshutemo-mobl1>
 <20190319134724.GB3437@redhat.com> <20190319141416.GA3879@redhat.com>
 <20190319142918.6a5vom55aeojapjp@kshutemo-mobl1>
 <20190319153644.GB26099@quack2.suse.cz>
From:   John Hubbard <jhubbard@nvidia.com>
X-Nvconfidentiality: public
Message-ID: <99882bf1-1db8-fd2c-cc72-2a6ea8ea4f89@nvidia.com>
Date:   Tue, 19 Mar 2019 12:02:32 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <20190319153644.GB26099@quack2.suse.cz>
X-Originating-IP: [10.124.1.5]
X-ClientProxiedBy: HQMAIL101.nvidia.com (172.20.187.10) To
 HQMAIL101.nvidia.com (172.20.187.10)
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US-large
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
        t=1553022138; bh=NZoJbC8WOTr0NdLPHDxUPPIt9/DJYfgztYt8n26Np0U=;
        h=X-PGP-Universal:Subject:To:CC:References:From:X-Nvconfidentiality:
         Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:
         X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language:
         Content-Transfer-Encoding;
        b=cEUH3Lqw9UBui8Fl9HmBEvNVfx73iPEdZqVl+LLKqXgHVwB0VcSbDy385l75xJqu5
         331YZ/UQtFcSBuZnrKiQz6kQOIs07Y/L9OVI0ot2hjFtbEzxLPlHH6RHrAxg5oRzHy
         7jnl03iZU4oMHJiDR4HmuuR04+8nBrMtK1y4qb3b38mhnm4ZNsfBH9v88Pw5q+3XHh
         1L4YW/u593GRa+5uQQo71uYfBXVoLojpt+lxUXMJKnsIY9pWVT/vLyfF57No+6qBeJ
         RUvCPIT0OiytlsDBsz/EGmWiyI2RDo/55GN4obyJ++mj4Ll3E8oWcXLEgy2jbDWpZd
         8AHmcW7zcs33g==
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 3/19/19 8:36 AM, Jan Kara wrote:
> On Tue 19-03-19 17:29:18, Kirill A. Shutemov wrote:
>> On Tue, Mar 19, 2019 at 10:14:16AM -0400, Jerome Glisse wrote:
>>> On Tue, Mar 19, 2019 at 09:47:24AM -0400, Jerome Glisse wrote:
>>>> On Tue, Mar 19, 2019 at 03:04:17PM +0300, Kirill A. Shutemov wrote:
>>>>> On Fri, Mar 08, 2019 at 01:36:33PM -0800, john.hubbard@gmail.com wrote:
>>>>>> From: John Hubbard <jhubbard@nvidia.com>
>>>> [...]
>>> Forgot to mention one thing, we had a discussion with Andrea and Jan
>>> about set_page_dirty() and Andrea had the good idea of maybe doing
>>> the set_page_dirty() at GUP time (when GUP with write) not when the
>>> GUP user calls put_page(). We can do that by setting the dirty bit
>>> in the pte for instance. They are few bonus of doing things that way:
>>>     - amortize the cost of calling set_page_dirty() (ie one call for
>>>       GUP and page_mkclean()
>>>     - it is always safe to do so at GUP time (ie the pte has write
>>>       permission and thus the page is in correct state)
>>>     - safe from truncate race
>>>     - no need to ever lock the page
>>>
>>> Extra bonus from my point of view, it simplify thing for my generic
>>> page protection patchset (KSM for file back page).
>>>
>>> So maybe we should explore that ? It would also be a lot less code.
>>
>> Yes, please. It sounds more sensible to me to dirty the page on get, not
>> on put.
> 
> I fully agree this is a desirable final state of affairs. And with changes
> to how we treat pinned pages during writeback there won't have to be any
> explicit dirtying at all in the end because the page is guaranteed to be
> dirty after a write page fault and pin would make sure it stays dirty until
> unpinned. However initially I want the helpers to be as close to code they
> are replacing as possible. Because it will be hard to catch all the bugs
> due to driver conversions even in that situation. So I still think that
> these helpers as they are a good first step. Then we need to convert
> GUP users to use them and then it is much easier to modify the behavior
> since it is no longer opencoded in two hudred or how many places...
> 
> 								Honza

In fact, we had this very same question come up last month [1]: I was also
wondering if we should just jump directly to the final step, and not
do the dirtying call, but it is true that during the conversion process,
(which effectively wraps put_page(), without changing anything else),
it's safer to avoid changing things. 

The whole system is fragile because it's running something that has some 
latent bugs in this area, so probably best to do it the way Jan says, and 
avoid causing any new instances of reproducing this problem, even though 
there is a bit more churn involved.


[1] https://lore.kernel.org/r/20190205112107.GB3872@quack2.suse.cz

thanks,
-- 
John Hubbard
NVIDIA