On 23.07.24 23:44, Jason Gunthorpe wrote:
On Tue, Jul 23, 2024 at 11:36:51PM +0200, David Hildenbrand wrote:
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 ...
I admit I barely understand what x86 uses this PAT stuff for -
allowing WC mappings is part of it?
I'm confused by all of that, but I think yes :)
If yes, then RDMA would expect WC PFN MAP VMAs to copy their WCness
during fork..
Okay, that answers that question: we have to support fork().
During fork() we call vm_ops->open when cloning the VMA. So the backend
can realize when all users (VMAs, whatsoever) are gone to undo any
registration. Maybe that's a path forward. But still no clue on details
... one important step might be figuring out who exactly really relies
on that VM_PAT handling.
--
Cheers,
David / dhildenb