Re: [PATCH 1/2] mm: always call rmap_walk() on locked folios

[David Hildenbrand <david@redhat.com>]

On 06.10.25 21:49, Peter Xu wrote:
> On Mon, Oct 06, 2025 at 08:43:17AM +0200, David Hildenbrand wrote:
>> On 04.10.25 01:02, Peter Xu wrote:
>>> On Thu, Oct 02, 2025 at 09:22:45AM +0200, David Hildenbrand wrote:
>>>> Staring at mf_generic_kill_procs() once again, we have this
>>>>
>>>> switch (pgmap->type) {
>>>> case MEMORY_DEVICE_PRIVATE:
>>>> case MEMORY_DEVICE_COHERENT:
>>>> 	rc = -ENXIO;
>>>> 	goto unlock;
>>>> ...
>>>> }
>>>>
>>>> IIRC, all anon device folios are MEMORY_DEVICE_PRIVATE, so we should
>>>> actually not succeed in this function and just abort.
>>>
>>> The doc says:
>>>
>>>    * MEMORY_DEVICE_PRIVATE:
>>>    * Device memory that is not directly addressable by the CPU: CPU can neither
>>>    * read nor write private memory. In this case, we do still have struct pages
>>>    * backing the device memory. Doing so simplifies the implementation, but it is
>>>    * important to remember that there are certain points at which the struct page
>>>    * must be treated as an opaque object, rather than a "normal" struct page.
>>>
>>> It does not intepret to anon private memories, but something that the cpu
>>> cannot access..
>>
>> I would not trust the docs that much ;)
>>
>> We establish device-private folios when a driver requests to migrate an
>> ordinary (non-zone-device) anonymous folio to device-private memory (e.g.,
>> due to a device page fault).
>>
>> When the CPU re-accesses that memory, we spot a device-private entry and
>> trigger migration back from device-private memory to ordinary
>> (CPU-accessible) RAM.
>>
>> The latter is triggered in do_swap_page() where we handle
>> is_device_private_entry() to call pgmap->ops->migrate_to_ram(vmf);
>>
>> For migration and everything around that to work, obviously the
>> device-private page also must be anonymous.
>>
>> It'a s bit more obvious in copy_nonpresent_pte() where we call
>> folio_try_dup_anon_rmap_pte() for is_device_private_entry(), because these
>> are just anonymous folios.
> 
> Ah, I actually didn't expect folio_test_anon() will return true for the
> ZONE_DEVICE folios that replaced a previously private anon folios..
> 
> To me, that was only some housekeeping for the ZONE_DEVICE folios
> remembering the mapping/index/... somewhere, so that when they got migrated
> back to private anon we know how to recover these things.  It doesn't mean
> it's a "real" anon private?

Just like other anonymous folios we can walk the rmap to unmap/migrate 
them. And just like anonymous folios, they are not added to a page cache.

COW-sharing etc. works the very same way for them.

So I think they are really just anonymous folios representing a chunk of 
device memory that is not addressable by the CPU. Apart from that, 
nothing should be too special about them (well, except the way they are 
mapped into page tables of course).

> After all, it's a ZONE_DEVICE folio, and the
> memmap does not 1:1 maps to some RAM backends.
> 
> But I confess I'm not familiar with these.  Fortunately, I think either way
> it doesn't seem to affect the design of the series being reviewed.

Yes.

-- 
Cheers

David / dhildenb