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

[Peter Xu <peterx@redhat.com>]

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

The only way to inteprete this from reading dax_lock_folio() is
folio->mapping should normally points to a real address_space of dax but
never an anon_vma, otherwise dax_mapping() looks inproper indeed.

So I also agree with the conclusion so far, looks like it should be good to
ignore the dax path for this problem.

Thanks,

-- 
Peter Xu