Re: [PATCH v1] x86/mm/pat: fix VM_PAT handling in COW mappings

[David Hildenbrand]

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