Re: [RFC, PATCH 00/12] userfaultfd: working set tracking for VM guest memory

From: David Hildenbrand (Arm)

Date: Wed Apr 22 2026 - 14:27:49 EST


On 4/22/26 11:27, Kiryl Shutsemau wrote:
> On Tue, Apr 21, 2026 at 03:33:27PM +0100, Kiryl Shutsemau wrote:
>>> 3) Some other stuff needs a second thought, like
>>>
>>> diff --git a/mm/gup.c b/mm/gup.c
>>> index 8e7dc2c6ee738..08fc18f1290d4 100644
>>> --- a/mm/gup.c
>>> +++ b/mm/gup.c
>>> @@ -695,7 +695,8 @@ static inline bool can_follow_write_pmd(pmd_t pmd, struct page *page,
>>> /* ... and a write-fault isn't required for other reasons. */
>>> if (pmd_needs_soft_dirty_wp(vma, pmd))
>>> return false;
>>> - return !userfaultfd_huge_pmd_wp(vma, pmd);
>>> + return !userfaultfd_huge_pmd_wp(vma, pmd) &&
>>> + !userfaultfd_huge_pmd_rwp(vma, pmd);
>>> }
>>>
>>> How can a pte be writable and prot_none at the same time? Maybe just confused AI
>>> output that you should carefully double check before sending that out officially.
>>
>> Note that this path is for !pmd_write() case to begin with. It serves
>> FOLL_FORCE case. I believe this check is correct: we don't want to allow
>> to write to such pages even with FOLL_FORCE.
>>
>> But looking around, I missed gup_can_follow_protnone() modification. It
>> has to return false for RWP.
>
> With gup_can_follow_protnone() fixed, the checks in
> can_follow_write_pmd/pte() are redundant. Will drop them.

Yes, that sounds better.

--
Cheers,

David