Re: [PATCH] mm: don't ioremap COWed anon pages in generic_access_phys()

From: David Hildenbrand (Arm)

Date: Fri Oct 02 2026 - 10:32:17 EST


On 10/2/26 16:03, Lorenzo Stoakes (ARM) wrote:
> On Fri, Oct 02, 2026 at 02:19:00PM +0200, David Hildenbrand (Arm) wrote:
>> On 10/2/26 12:09, Lorenzo Stoakes (ARM) wrote:
>>>
>>> Well, my series at least makes it easier to reason about VMA_IO_BIT!
>>>
>>> Though not sure if it really touches PFN map cases specifically.
>>
>> I'm more concerned about someone using this function on VM_MIXEDMAP | VM_IO with
>> a memory page that has a struct page but is actually not memory. So we could get
>> something that vm_normal_page() would flag but generic_access_phys() could
>> actually read ... I'll have to explore the generic_access_phys() users once more.
>
> Hmm that could be a problem also for struct page's that are there but you're not
> supposed to access for other reasons to as well?
>
> Definitely need to be careful about that.
>
>>
>> All way to complicated (and you series improves things).
>
> :) well there's still a lot of complexity in there, one battle at a time...

My conclusion so far is: indicating is_normal should work when using it in
generic_access_phys(), as it is never used on non-VM_PFNMAP VMAs.

follow_pfnmap_start(), however, can be called on some non-VM_PFNMAP-but-VM_IO
VMAs from KVM as it seems.

So we cannot easily restrict follow_pfnmap_start() to VM_PFNMAP only (weird,
right?) without risking breaking some weird KVM use case. Gah.

Anyhow, I'll prepare a fix for this one and send it out likely later today.

--
Cheers,

David