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;
MIME-Version: 1.0
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> <8590eb4c-256b-9ab0-5291-de8ec8d75276@nvidia.com>
In-Reply-To: <8590eb4c-256b-9ab0-5291-de8ec8d75276@nvidia.com>
From:   Souptick Joarder <jrdr.linux@gmail.com>
Date:   Mon, 9 Nov 2020 09:06:54 +0530
Message-ID: <CAFqt6zZkDm8Eg36Lakb6Y=ePp78pa2wkJkD+w15E=5qa9ohYQA@mail.gmail.com>
Subject: Re: [PATCH 1/2] tomoyo: Convert get_user_pages*() to pin_user_pages*()
To:     John Hubbard <jhubbard@nvidia.com>
Cc:     Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
        linux-security-module <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>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Nov 8, 2020 at 7:47 AM John Hubbard <jhubbard@nvidia.com> wrote:
>
> 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.)

Sure John, I will take it.