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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 10/2/26 12:07, Lorenzo Stoakes (ARM) wrote:
> On Fri, Oct 02, 2026 at 12:02:15PM +0200, David Hildenbrand (Arm) wrote:
>> On 10/2/26 10:38, Lorenzo Stoakes (ARM) wrote:
> 
>>> So I'd say somebody from the core team should take over this if we want to
>>> come up with a patch.
>>
>> Yes, I'll take care of it.
> 
> Thanks!
> 
>>>
>>> This looks reasonable but I hate that we have 'special' CoW overrides like
>>> this :)
>>
>> 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().
>>
>> Then we can just refuse all of these.
> 
> Yeah it's all a bit tricky.
> 
> Maybe is_vm_normal_page ?
> 
> Or do we want to default to referring to a folio... but then pfnmap not a
> folio... ugh.
> 
> is_normal?
> 
> With a comment explaining in sense of vm_normal_page/folio()?
> 
> 
>>>
>>> Hmm, if not defined before why would this need a new PUD handler? Do we
>>> even have PUD-leaf PFN mappings?
>>
>> Yes we do. In any case, good for consistency.
> 
> In that case then we should definitely have it!
> 
>>> Since a folio being 'anon' is vague, because we stupidly made 'anon' vague
>>> in general.
>>
>> For folios it's an established term :)
> 
> Yeah, fair enough, that is true.
> 
> And makes the anon folio -> tracked as such in my change consistent end-to-end.
> 
> I guess we have swapbacked for the shmem stuff as a clear delineation too.

The more I look into it, the more complicated it gets.

generic_access_phys() is only used on VM_PFNMAP, so far so good.

Handling CoW anonymous folios is easy, per previous discussion.

What's not so easy is handling when a driver allocates some pages and
remap_pfn_range's them in here. And apparently there are some HV thingies that
can end up in this.

We can try detecting pfn_valid() and refuse accessing them entirely. But that
might refuse some ranges that just happen to have a memmap.

I tried throwing in a page_is_ram() check but that also just has too many corner
cases.

I'll ponder some more about this ...

-- 
Cheers,

David