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
