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

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

On 4/23/26 22:10, Peter Xu wrote:
> On Thu, Apr 23, 2026 at 09:25:30PM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> The other thing is, as I mentioned in the other email, I still don't know
>>> how the current RW protection would work for anonymous.  I don't yet think
>>> the user swapper can read the anon page with RW-protected pgtables.  So far
>>> my understanding is maybe you only care about shmem so it's fine, but it'll
>>> always be great to confirm with you.
>>
>> I wonder if uffdio_move could be used for a swapper implementation instead?
> 
> If RW is justified to be useful first, maybe.
> 
> I had a gut feeling Kirill's use case doesn't use anon at all, then if
> nobody needs it we can still decide to not support anon.
> 
>>
>> If we ever have to read from a protnone page, maybe we could teach ptrace access
>> to do it, or have something that can read from prot_none areas -- like
>> uffdio_copy, which can write to prot-none areas.
> 
> Somethinig like swap_access() in my proposal can also partly achieve that.

Looks more like the hammer for the nail here: we could fault the page in just
fine, while keeping it mapped prot_none and keeping the uffd-rwp pte bit set.

I was rather thinking of some uffd-specific thing that can read from a uffd-rwp
protected pte without trigger uffd.

> 
> https://lore.kernel.org/all/aYuad2k75iD9bnBE@x1.local/
> 
> There, it was only about reading from swap so far, though.  But that one
> might be easier to be extended to read PROT_NONE and directly put data into
> buffer user specified (ps: in my local tree impl I named it maccess() to
> pair with mincore(), but it doesn't really matter; it doesn't even need to
> be a syscall..).
> 
> To me, the interfacing is not a major issue.  The major question I have is
> why RW protection can help in swap system impl when we already have uffd-wp.
> 
> So I want to make sure the use case can't be implemented by uffd-wp already.
> Because that's really what we might do for QEMU.

There has to be some added value indeed.

-- 
Cheers,

David