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

[Lorenzo Stoakes (ARM)]

On Fri, Oct 02, 2026 at 02:19:00PM +0200, David Hildenbrand (Arm) wrote:
> On 10/2/26 12:09, Lorenzo Stoakes (ARM) wrote:
> > On Fri, Oct 02, 2026 at 12:04:27PM +0200, David Hildenbrand (Arm) wrote:
> >> On 10/2/26 12:02, David Hildenbrand (Arm) wrote:
> >>>
> >>> Yes, I'll take care of it.
> >>>
> >>> [...]
> >>>
> >>> After sending this yesterday, I concluded that we can do this cleaner: just have
> >>>
> >>> bool normal_page;
> >>>
> >>> (naming suggestions?)
> >>>
> >>> that express that this is something refcounted with a struct page, like
> >>> documented for vm_normal_page().
> >>
> >> Hmm, have to think about that once more, regarding VM_IO and if there are some
> >> cases that would actually have to work in generic_access_phys().
> >
> > 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...

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo