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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 4/19/26 16:33, Kiryl Shutsemau wrote:
> On Fri, Apr 17, 2026 at 01:26:34PM +0100, Kiryl Shutsemau wrote:
>>> Leaving NUMA-balancing aside, a simple
>>> mprotect(PROT_NONE)+mprotect(PROT_READ) would already be problematic to
>>> distinguish both cases.
>>
>> Hm. I didn't consider this case (miss some uffd lore). Will rework to
>> reuse existing PTE bit.
> 
> See https://git.kernel.org/pub/scm/linux/kernel/git/kas/linux.git uffd/rfc-v3
> 

Quick feedback from skimming over it:


1) ARCH_SUPPORTS_PROT_NONE needs some thought, because I am pretty sure all 
architectures support something like mprotect(PROT_NONE), and the config
option might be misleading.

So you very likely want to express different semantics here. You want to
know whether pte_protnone()/pmd_protnone() works.


2) The other stuff is really just an extension of existing WP handling.
I suspect we want to have some reasonable cleanups to not end up in
common code with

@@ -1841,7 +1841,7 @@ static void copy_huge_non_present_pmd(
 	add_mm_counter(dst_mm, MM_ANONPAGES, HPAGE_PMD_NR);
 	mm_inc_nr_ptes(dst_mm);
 	pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable);
-	if (!userfaultfd_wp(dst_vma))
+	if (!userfaultfd_wp(dst_vma) && !userfaultfd_rwp(dst_vma))
 		pmd = pmd_swp_clear_uffd_wp(pmd);
 	set_pmd_at(dst_mm, addr, dst_pmd, pmd);

All the uffd handling should be better isolated (i.e., a single vma check?),
and likely the uffd bit should be abstracted away from being called "wp" to
something more generic.

Maybe it's simply a "uffd" flag which's semantics depend
on the vma flags.

Maybe something like:

@@ -1841,7 +1841,7 @@ static void copy_huge_non_present_pmd(
 	add_mm_counter(dst_mm, MM_ANONPAGES, HPAGE_PMD_NR);
 	mm_inc_nr_ptes(dst_mm);
 	pgtable_trans_huge_deposit(dst_mm, dst_pmd, pgtable);
	if (!userfaultfd_uses_pte_bit(dst_vma))
 		pmd = pmd_swp_clear_uffd(pmd);
 	set_pmd_at(dst_mm, addr, dst_pmd, pmd);

Not sure, needs another thought. But I think there are some decent
cleanups to be had.


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.


4) How do we want to handle PM_UFFD_WP?

We are pretty much out of flags soon. Overloading PM_UFFD_WP means that we will not
be able to easily support using a separate bit.

But our internal design will not easily allow that either, and I am not really
sure we want to go down that path any time soon.

Maybe we could document this for now as "In WP VMAs, indicated WP PTEs.
Otherwise, in RWP VMAs, indicates RWP.". Whenever we would allow both at the
same time, we could change the semantics. User space would fail to create one
with both protection types for now either way.


-- 
Cheers,

David