[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5efeb909-3e02-ba14-7a86-f18562a2fe69@i-love.sakura.ne.jp>
Date: Sun, 8 Nov 2020 10:13:55 +0900
From: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To: John Hubbard <jhubbard@...dia.com>,
Souptick Joarder <jrdr.linux@...il.com>
Cc: linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, Jan Kara <jack@...e.cz>,
Matthew Wilcox <willy@...radead.org>,
James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: [PATCH 1/2] tomoyo: Convert get_user_pages*() to
pin_user_pages*()
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() ?
Powered by blists - more mailing lists