Re: [PATCH v1] x86/mm/pat: fix VM_PAT handling when fork() fails in copy_page_range()

[Peter Xu <peterx@redhat.com>]

On Tue, Oct 29, 2024 at 10:03:31PM +0100, David Hildenbrand wrote:
> If track_pfn_copy() fails, we already added the dst VMA to the maple
> tree. As fork() fails, we'll cleanup the maple tree, and stumble over
> the dst VMA for which we neither performed any reservation nor copied
> any page tables.
> 
> Consequently untrack_pfn() will see VM_PAT and try obtaining the
> PAT information from the page table -- which fails because the page
> table was not copied.
> 
> The easiest fix would be to simply clear the VM_PAT flag of the dst VMA
> if track_pfn_copy() fails. However, the whole thing is about "simply"
> clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()
> and performed a reservation, but copying the page tables fails, we'll
> simply clear the VM_PAT flag, not properly undoing the reservation ...
> which is also wrong.

David,

Sorry to not have chance yet reply to your other email..

The only concern I have with the current fix to fork() is.. we started to
have device drivers providing fault() on PFNMAPs as vfio-pci does, then I
think it means we could potentially start to hit the same issue even
without fork(), but as long as the 1st pgtable entry of the PFNMAP range is
not mapped when the process with VM_PAT vma exit()s, or munmap() the vma.

So I do feel like at some point we still need to make get_pat_info() work
without walking the pgtable, so as to fix all possible such issues.

Thanks,

-- 
Peter Xu