Re: [PATCH] mm/x86/pat: Only untrack the pfn range if unmap region

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux