On 14.03.24 17:42, David Hildenbrand wrote:
On 12.03.24 20:38, David Hildenbrand wrote:
On 12.03.24 20:22, Matthew Wilcox wrote:
On Tue, Mar 12, 2024 at 07:11:18PM +0100, David Hildenbrand wrote:
PAT handling won't do the right thing in COW mappings: the first PTE
(or, in fact, all PTEs) can be replaced during write faults to point at
anon folios. Reliably recovering the correct PFN and cachemode using
follow_phys() from PTEs will not work in COW mappings.
I guess the first question is: Why do we want to support COW mappings
of VM_PAT areas? What breaks if we just disallow it?
Well, that was my first approach. Then I decided to be less radical (IOW
make my life easier by breaking less user space) and "fix it" with
minimal effort.
Chances of breaking some weird user space is possible, although I
believe for most such mappings MAP_PRIVATE doesn't make too much sense
sense.
Nasty COW support for VM_PFNMAP mappings dates back forever. So does PAT
support.
I can try finding digging through some possible user space users tomorrow.
As discussed, MAP_PRIVATE doesn't make too much sense for most PFNMAP
mappings.
However, /dev/mem and /proc/vmcore are still used with MAP_PRIVATE in
some cases.
Side note: /proc/vmcore is a bit weird: mmap_vmcore() sets VM_MIXEDMAP,
and then we might call remap_pfn_range(), which sets VM_PFNMAP. I'm not
so sure if that's what we want to happen ...
Correction: at least mmap_vmcore() ends up clearing VM_MAYWRITE. So no
COW mapping. We could do the same to at least keep PROT_READ|MAP_PRIVATE
working. If user space specified PROT_WRITE for whatever reason, it's
not that easy.
--
Cheers,
David / dhildenb
