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

[Peter Xu <peterx@redhat.com>]

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?  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.

Thanks,

-- 
Peter Xu