On 23.07.24 22:27, Peter Xu wrote:
On Mon, Jul 22, 2024 at 11:17:57AM +0200, David Hildenbrand wrote:
What we do have is a single VMA, whereby within that VMA we place various
different PFN ranges. (randomly looking at drivers/video/fbdev/smscufx.c)
These wouldn't have triggered VM_PAT code.
Right, it looks like VM_PAT is only applying to a whole-vma mapping, even
though I don't know how that was designed..
I wished vma->vm_pgoff was for storing the base PFN for VM_SHARED too: now
it only works like that for CoW mappings in remap_pfn_range_notrack(), then
it looks like VM_SHARED users of remap_pfn_range() can reuse vm_pgoff, and
I think VFIO does reuse it at least..
I am a bit confused on why Linux made that different for VM_SHARED,
probably since b3b9c2932c32 ("mm, x86, pat: rework linear pfn-mmap
tracking"). I wished vm_pgoff was always used for internal maintenance
(even for VM_SHARED) so this issue should be easier to solve.
Maybe we can still re-define vm_pgoff for VM_SHARED pfnmaps? The caller
should always be able to encode information in vm_private_data anyway.
But I think that might break OOT users..
Yeah, I played with this idea when trying to remove the page table walk
and storing it in the VMA, avoiding consuming more memory. The vm_pgoff
usage for VM_PFNMAP mappings that I could spot looked nasty enough for
me to not dare trying.
I wonder if we could just let relevant users do the PAT handling
manually: I'm also not sure how many remap_pfn_range users end up
triggering VM_PAT code although they don't really have to (just because
they happen to cover a full VMA)?
One nasty thing is fork(), I was wondering if relevant users really rely
on that or if we could force these VMAs to simply not get copied during
fork. During fork() we have to "duplicate" the reservation ...
No real solution yet :/ Getting id of the page table walk is possible (I
can try digging up the patch I was able to come up with), but it feels
like the wrong approach.
The owner of the VMA should have that information ...
--
Cheers,
David / dhildenb
