On Thu, 18 Feb 2021 19:04:04 -0400 Jason Gunthorpe <jgg@xxxxxxxxxx> wrote: > On Thu, Feb 18, 2021 at 02:56:06PM -0700, Alex Williamson wrote: > > > Looks pretty slick. I won't claim it's fully gelled in my head yet, > > but AIUI you're creating these inodes on your new pseudo fs and > > associating it via the actual user fd via the f_mapping pointer, which > > allows multiple fds to associate and address space back to this inode > > when you want to call unmap_mapping_range(). > > Yes, from what I can tell all the fs/inode stuff is just mandatory > overhead to get a unique address_space pointer, as that is the only > thing this is actually using. > > I have to check the mmap flow more carefully, I recall pointing to a > existing race here with Daniel, but the general idea should hold. > > > That clarifies from the previous email how we'd store the inode on > > the vfio_device without introducing yet another tracking list for > > device fds. > > Right, you can tell from the vma what inode it is for, and the inode > can tell you if it is a VFIO VMA or not, so no tracking lists needed > at all. Seems to be a nice cleanup for vfio as well, more testing and analysis required, but here are a few (4) wip commits that re-implement the current vma zapping scheme following your example: https://github.com/awilliam/linux-vfio/commits/vfio-unmap-mapping-range Thanks, Alex
