]> www.infradead.org Git - users/jedix/linux-maple.git/commit
vfio/pci: Use unmap_mapping_range()
authorAlex Williamson <alex.williamson@redhat.com>
Thu, 30 May 2024 04:52:31 +0000 (22:52 -0600)
committerAlex Williamson <alex.williamson@redhat.com>
Fri, 31 May 2024 21:15:51 +0000 (15:15 -0600)
commitaac6db75a9fc2c7a6f73e152df8f15101dda38e6
treeb448ec493f4bdd8b03634479c52b080211ad39ac
parentb7c5e64fecfa88764791679cca4786ac65de739e
vfio/pci: Use unmap_mapping_range()

With the vfio device fd tied to the address space of the pseudo fs
inode, we can use the mm to track all vmas that might be mmap'ing
device BARs, which removes our vma_list and all the complicated lock
ordering necessary to manually zap each related vma.

Note that we can no longer store the pfn in vm_pgoff if we want to use
unmap_mapping_range() to zap a selective portion of the device fd
corresponding to BAR mappings.

This also converts our mmap fault handler to use vmf_insert_pfn()
because we no longer have a vma_list to avoid the concurrency problem
with io_remap_pfn_range().  The goal is to eventually use the vm_ops
huge_fault handler to avoid the additional faulting overhead, but
vmf_insert_pfn_{pmd,pud}() need to learn about pfnmaps first.

Also, Jason notes that a race exists between unmap_mapping_range() and
the fops mmap callback if we were to call io_remap_pfn_range() to
populate the vma on mmap.  Specifically, mmap_region() does call_mmap()
before it does vma_link_file() which gives a window where the vma is
populated but invisible to unmap_mapping_range().

Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Link: https://lore.kernel.org/r/20240530045236.1005864-3-alex.williamson@redhat.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
drivers/vfio/pci/vfio_pci_core.c
include/linux/vfio_pci_core.h