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? > 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? 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? Thanks Nicolin