Re: [PATCH] mm: fix COW mapping handing in generic_access_phys

[David Hildenbrand <david@redhat.com>]

>> No idea what VM_IO | VM_MIXEDMAP is supposed to mean. Only the special
>> ptes need io accessors?
>>
>> In either case GUP doesn't really work on the VMA. PFNMAP is totally
>> blocked, and for MIXEDMAP userspace has no way to discover which
>> subset of the VMA is GUPable. I think that GUP is supported on
>> MIXEDMAP at all is a bit of a weirdo thing.
> 
> Does it imply that in the ideal case one should use follow_pfnmap_start()
> for MIXEDMAP?
> 
> I don't have a strong feeling yet on how GUP should treat MIXEDMAP, either
> (1) fail MIXEDMAP like you said, falling back to follow_pfnmap_start(), or
> (2) allow MIXEDMAP only on page-backed mappings, then fallback to
> follow_pfnmap_start() on non-page-backed mappings only.

I think GUP should GUP when there is a page to GUP.

If there is no page to GUP, then we have a PFNMAP and should fallback to 
follow_pfnmap_start() indeed.

And now I realize that MIXEDMAP should indeed be working with 
follow_pfnmap_start(). But I think it should only deal with actual 
non-struct page thingies.

GUP not supporting COW'ed pages in a VM_PFNMAP is something we should 
likely just fix. It would likely also fix the problem here, because the 
anonymous page would simply be returned by GUP.

I mean, GUP-fast should work on COW'ed pages in a VM_PFNMAP already ...

-- 
Cheers,

David / dhildenb