On Mon, May 05, 2025 at 01:07:34PM -0700, Nicolin Chen wrote:
> On Mon, May 05, 2025 at 02:28:13PM -0300, Jason Gunthorpe wrote:
> > On Mon, May 05, 2025 at 10:21:03AM -0700, Nicolin Chen wrote:
> > > > > > +void iommufd_ctx_free_mmap(struct iommufd_ctx *ictx, unsigned long
> > > > > > immap_id)
> > > > > > +{
> > > > > > + kfree(mtree_erase(&ictx->mt_mmap, immap_id >> PAGE_SHIFT));
> > > > >
> > > > > MMIO lifecycle question: what happens if a region is removed from the
> > > > > maple tree (and is therefore no longer mappable), but is still mapped
> > > > > and in use by userspace?
> > > >
> > > > I think we should probably zap it and make any existing VMAs
> > > > SIGBUS... Otherwise it is hard to reason about from the kernel side
> > >
> > > I added in v3 a pair of open/close op that would refcount the
> > > vIOMMU object (owner of the mmap region). This would EBUSY the
> > > vIOMMU destroy ioctl that would call this function.
> >
> > That's no good, we can't have VMAs prevent cleaning up iommufd
>
> Hmm, would you please elaborate why?
It would create weird dependencies in the kernel that become hard to
manage. If we really need to unplug the PFNs behind the VMA for some
reason then we should always allow that to progress. Requiring the VMA
to be unmapped first is not great.
> > objects, the right thing is to zap it with invalidate_mapping_range()
>
> Also, I can't find much info about invalidate_mapping_range(). Is
> it a user space call?
unmap_mapping_range(), see how VFIO uses it.
> I do see a few drivers defining a fault op in vm_operations_struct,
> where VM_FAULT_SIGBUS is returned when there is page backing up the
> VMAs. Is it what we need here?
Probably as well
Jason
