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;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
Subject: Re: [PATCH] mm: reuse the unshared swapcache page in do_wp_page
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <8931808d-db61-0f06-ceb3-f48a83b1f74c@redhat.com>
Date:   Thu, 20 Jan 2022 10:11:06 -0800
Cc:     "zhangliang (AG)" <zhangliang5@huawei.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linux-MM <linux-mm@kvack.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        wangzhigang17@huawei.com, Matthew Wilcox <willy@infradead.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6225EAFF-B323-4DC5-AC4C-885B29ED7261@gmail.com>
References: <20220113140318.11117-1-zhangliang5@huawei.com>
 <YeA5oP/iaxtVPHb3@casper.infradead.org>
 <CAHk-=wjB0i-B=U-DhpAajQx3f6bp1X==neLOrg0jwq29mgz=3g@mail.gmail.com>
 <172ccfbb-7e24-db21-7d84-8c8d8c3805fd@redhat.com>
 <a93988da-80fb-dd32-4717-a6a0bae9e4ee@huawei.com>
 <dc415c4a-63aa-19b0-0fbc-795989970f6d@redhat.com>
 <fb02087a-b102-c91e-ab65-fb02cc8ee0a2@huawei.com>
 <9cd7eee2-91fd-ddb8-e47d-e8585e5baa05@redhat.com>
 <b6df4f7f-c080-ad6c-d1ad-098115f016f3@huawei.com>
 <747ff31c-6c9e-df6c-f14d-c43aa1c77b4a@redhat.com>
 <C8734D0B-B855-4323-A7DF-2D96245951B2@gmail.com>
 <8931808d-db61-0f06-ceb3-f48a83b1f74c@redhat.com>
To:     David Hildenbrand <david@redhat.com>
Precedence: bulk


> On Jan 20, 2022, at 10:00 AM, David Hildenbrand <david@redhat.com> =
wrote:
>=20
> On 20.01.22 18:48, Nadav Amit wrote:
>>=20
>>> On Jan 20, 2022, at 6:15 AM, David Hildenbrand <david@redhat.com> =
wrote:
>>>=20
>>> On 17.01.22 14:31, zhangliang (AG) wrote:
>>>> Sure, I will do that :)
>>>=20
>>> I'm polishing up / testing the patches and might send something out =
for discussion shortly.
>>> Just a note that on my branch was a version with a wrong condition =
that should have been fixed now.
>>>=20
>>=20
>> Sorry for being late for the discussion.
>>=20
>> David, does any of it regards the lru_cache_add() reference issue =
that I
>> mentioned? [1]
>=20
> No, unfortunately not in that part of my work. *Maybe* we could also =
try
> to handle that reference similarly to the swapcache, but the question =
is
> if we can't wait for PageAnonExclusive.
>=20
> Right now I have the following in mind to get most parts working as
> exptected:
>=20
> 1. Optimize reuse logic for the swapcache as it seems to be easy
> 2. Streamline COW logic and remove reuse_swap_page() -- fix the CVE =
for
>   THP.
> 3. Introduce PageAnonExclusive and allow FOLL_PIN only on
>   PageAnonExclusive pages.
> 4. Convert O_DIRECT to FOLL_PIN
>=20
> We will never ever have to copy a page PageAnonExclusive page in the =
COW
> handler and can immediately reuse it without even locking the page. =
The
> existing reuse logic is essentially then used to reset =
PageAnonExclusive
> on a page (thus it makes sense to work on it) where the flag is not =
set
> anymore -- or on a fresh page if we have to copy.
>=20
> That implies that all these additional references won't care if your =
app
> doesn't fork() or KSM isn't active. Consequently, anything that
> read-protects anonymous pages will work as expected and should be as
> fast as it gets.
>=20
> Sounds good? At least to me. If only swap/migration entries wouldn't =
be
> harder to handle than I'd wish, that's why it's taking a little and =
will
> take a little longer.

Thanks for the quick response. I would have to see the logic to =
set/clear
PageAnonExclusive to fully understand how things are handled.

BTW, I just saw this patch form PeterZ [1] that seems to be related, as
it deals with changing protection on pinned pages.


[1] =
https://lore.kernel.org/linux-mm/20220120160822.666778608@infradead.org/=