Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp2320794pxb;
        Sat, 7 Nov 2020 18:23:45 -0800 (PST)
X-Google-Smtp-Source: ABdhPJwbN3u8Tao/mG3fcP2jWA08akEFPEQCRfBVb8PC9fuHjHM6oZRD5KdzWiEWmajpn2Q22UcZ
X-Received: by 2002:a17:906:a843:: with SMTP id dx3mr9338167ejb.313.1604802225136;
        Sat, 07 Nov 2020 18:23:45 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1604802225; cv=none;
        d=google.com; s=arc-20160816;
        b=lpC1Jq1Zj1Jtfizg80n9S1vlVl/vYLvj7zpcXTNV0YrbRKMVHyWETvTRZJWoztpv7+
         JixNHh2VMtmVx2We1RUP948Goj/a5VbAXDPI/YVCaeiC7xCo/fkR/Bd+HtZpi1RLGii9
         YQvTaIJLP+i9p7WZqHE2Or271ODEWP4DOEoL1YVyKIHaGeUjBXmujTDkbcbMj6P4sv1h
         NxM7rltcLtu9hjYboB4/yb4pXHDzQnYxobWcjQYU5bEeDSOCTp372MG2GH3CfP+CD+cZ
         S0N60U3R7pzQKxON+4Qq4UuDlpfIHGhO5L5FtmWLadHxqRCeMDuEq+LaRMrObY/EIG4M
         V5FQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-id:precedence:dkim-signature:content-transfer-encoding
         :content-language:in-reply-to:mime-version:user-agent:date
         :message-id:from:references:cc:to:subject;
        bh=bZw7mGT3w9m9Y7Dcs1zQ8kMzt3zbk0xOy0bnGCS8rTo=;
        b=VHmgGKPH0JUi7lHVXSdV3F0KtiTUhXL6LBuBteGQhI+1tWs+Wo37YrfAyL7vWiEHgv
         kDQdh7Axxomc3DEHBsqKiXU6nuIXikyWUdMr0MnoJxyegg0zLR5XrmZSIj6kXuGTHHbP
         zg8PytaPNmdV2CNWHV7VXuz9FdMgqwJWFCp9jgQr4u+TQl+3gygxTTKMv4OmGb320yxy
         NrJyM/BaOUmwPH6S3LKsZ55C9Ug898PoLmzPybWGIbtzXrH9kOaLVwQRa6xpNKvfz6o6
         aCW9DWPkMt8Nd3eCBTru5cH4wgBwzejMGEl7cdEmBCam0HuSzukfVsuymQrkSOn2bRxe
         5TNA==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@nvidia.com header.s=n1 header.b=KwQOvJlP;
       spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18])
        by mx.google.com with ESMTP id bm22si4362828edb.342.2020.11.07.18.22.49;
        Sat, 07 Nov 2020 18:23:45 -0800 (PST)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@nvidia.com header.s=n1 header.b=KwQOvJlP;
       spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728347AbgKHCRX (ORCPT <rfc822;hackukernel@gmail.com>
        + 99 others); Sat, 7 Nov 2020 21:17:23 -0500
Received: from hqnvemgate26.nvidia.com ([216.228.121.65]:4294 "EHLO
        hqnvemgate26.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1727432AbgKHCRX (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 7 Nov 2020 21:17:23 -0500
Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, AES256-SHA)
        id <B5fa755360000>; Sat, 07 Nov 2020 18:17:26 -0800
Received: from [10.2.62.222] (172.20.13.39) by HQMAIL107.nvidia.com
 (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 8 Nov
 2020 02:17:22 +0000
Subject: Re: [PATCH 1/2] tomoyo: Convert get_user_pages*() to
 pin_user_pages*()
To:     Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
        Souptick Joarder <jrdr.linux@gmail.com>
CC:     <linux-security-module@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, Jan Kara <jack@suse.cz>,
        Matthew Wilcox <willy@infradead.org>,
        James Morris <jmorris@namei.org>,
        "Serge E. Hallyn" <serge@hallyn.com>
References: <1604737451-19082-1-git-send-email-jrdr.linux@gmail.com>
 <e5401549-8c31-2c6d-58dd-864232de17af@nvidia.com>
 <e6859981-bc3c-9513-99e5-a99849786156@nvidia.com>
 <5efeb909-3e02-ba14-7a86-f18562a2fe69@i-love.sakura.ne.jp>
From:   John Hubbard <jhubbard@nvidia.com>
Message-ID: <8590eb4c-256b-9ab0-5291-de8ec8d75276@nvidia.com>
Date:   Sat, 7 Nov 2020 18:17:22 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <5efeb909-3e02-ba14-7a86-f18562a2fe69@i-love.sakura.ne.jp>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.20.13.39]
X-ClientProxiedBy: HQMAIL107.nvidia.com (172.20.187.13) To
 HQMAIL107.nvidia.com (172.20.187.13)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1;
        t=1604801846; bh=bZw7mGT3w9m9Y7Dcs1zQ8kMzt3zbk0xOy0bnGCS8rTo=;
        h=Subject:To:CC:References:From:Message-ID:Date:User-Agent:
         MIME-Version:In-Reply-To:Content-Type:Content-Language:
         Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy;
        b=KwQOvJlPbMb8l1LvLiXBuWlemKRJklt034S8TtxjqEZihTCiD8g5QN0t6wKKQvaHz
         +z976OMLMd1KuEPS0ePWMLkrj3uloIX+iq0Illa97fG+TlNx7rwVF48wLJFouyb6ii
         xynhFkFd3FCzClfGE5fSbeYcYSX+myRwpxMK8Hm6IrvA97g1UvojqfkF74l31PJIlW
         uVNdlnucxfihmp6tGOpfQo8jf2Xj6JugueL7ZgPPXfVG2D9rUXTbY5lon1CCjavKc+
         ngaO0ffk2mpxhMomkPXaQny4xj1znfBzODXVuFVRv1IbiNLwDh9taMExkRCtsuUz1P
         ErPRefHfMICVg==
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 11/7/20 5:13 PM, Tetsuo Handa wrote:
> On 2020/11/08 4:17, John Hubbard wrote:
>> On 11/7/20 1:04 AM, John Hubbard wrote:
>>> On 11/7/20 12:24 AM, Souptick Joarder wrote:
>>>> In 2019, we introduced pin_user_pages*() and now we are converting
>>>> get_user_pages*() to the new API as appropriate. [1] & [2] could
>>>> be referred for more information. This is case 5 as per document [1].
>>>
>>> It turns out that Case 5 can be implemented via a better pattern, as long
>>> as we're just dealing with a page at a time, briefly:
>>>
>>> lock_page()
>>> write to page's data
>>> unlock_page()
>>>
>>> ...which neatly synchronizes with writeback and other fs activities.
>>
>> Ahem, I left out a key step: set_page_dirty()!
>>
>> lock_page()
>> write to page's data
>> set_page_dirty()
>> unlock_page()
>>
> 
> Excuse me, but Documentation/core-api/pin_user_pages.rst says
> "CASE 5: Pinning in order to _write_ to the data within the page"
> while tomoyo_dump_page() is for "_read_ the data within the page".
> Do we want to convert to pin_user_pages_remote() or lock_page() ?
> 

Sorry, I missed the direction here, was too focused on the Case 5
aspect. Yes. Case 5 (which, again, I think we're about to re-document)
is only about *writing* to data within the page.

So in this case, where it is just reading from the page, I think it's
already from a gup vs pup point of view.

btw, it's not clear to me whether the current code is susceptible to any
sort of problem involving something writing to the page while it
is being dumped (I am curious). But changing from gup to pup wouldn't
fix that, if it were a problem. It a separate question from this patch.

(Souptick, if you're interested, the Case 5 documentation change and
callsite retrofit is all yours if you want it. Otherwise it's on
my list.)

thanks,
-- 
John Hubbard
NVIDIA