Re: [PATCH v2 13/22] iommufd: Add mmap interface

Nicolin Chen
2025-05-05T20:12:47Z

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