lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 14 Jun 2024 15:56:03 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [GIT PULL] VFIO fixes for v6.10-rc4

Hi Linus,

The following changes since commit 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0:

  Linux 6.10-rc1 (2024-05-26 15:20:12 -0700)

are available in the Git repository at:

  https://github.com/awilliam/linux-vfio.git tags/vfio-v6.10-rc4

for you to fetch changes up to d71a989cf5d961989c273093cdff2550acdde314:

  vfio/pci: Insert full vma on mmap'd MMIO fault (2024-06-12 15:40:39 -0600)

----------------------------------------------------------------
VFIO fixes for v6.10-rc4

 - Fix long standing lockdep issue of using remap_pfn_range() from
   the vfio-pci fault handler for mapping device MMIO.  Commit
   ba168b52bf8e ("mm: use rwsem assertion macros for mmap_lock") now
   exposes this as a warning forcing this to be addressed.

   remap_pfn_range() was used here to efficiently map the entire vma,
   but it really never should have been used in the fault handler and
   doesn't handle concurrency, which introduced complex locking.  We
   also needed to track vmas mapping the device memory in order to zap
   those vmas when the memory is disabled resulting in a vma list.

   Instead of all that mess, setup an address space on the device fd
   such that we can use unmap_mapping_range() for zapping to avoid
   the tracking overhead and use the standard vmf_insert_pfn() to
   insert mappings on fault.  For now we'll iterate the vma and
   opportunistically try to insert mappings for the entire vma.  This
   aligns with typical use cases, but hopefully in the future we can
   drop the iterative approach and make use of huge_fault instead,
   once vmf_insert_pfn{pud,pmd}() learn to handle pfnmaps.
   (Alex Williamson)

----------------------------------------------------------------
Alex Williamson (3):
      vfio: Create vfio_fs_type with inode per device
      vfio/pci: Use unmap_mapping_range()
      vfio/pci: Insert full vma on mmap'd MMIO fault

 drivers/vfio/device_cdev.c       |   7 +
 drivers/vfio/group.c             |   7 +
 drivers/vfio/pci/vfio_pci_core.c | 271 ++++++++++-----------------------------
 drivers/vfio/vfio_main.c         |  44 +++++++
 include/linux/vfio.h             |   1 +
 include/linux/vfio_pci_core.h    |   2 -
 6 files changed, 125 insertions(+), 207 deletions(-)


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ