> From: Nicolin Chen <nicol...@nvidia.com>
> Sent: Tuesday, May 6, 2025 4:08 AM
>
> 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?
>
According to [1]:
" The mmap() function adds an extra reference to the file associated
with the file descriptor fildes which is not removed by a subsequent
close() on that file descriptor. This reference is removed when there
are no more mappings to the file. "
what Nicoline proposed in v3 adopts a similar policy. So it kind of
makes sense to me, except that we should not return -EBUSY in
vIOMMU destroy ioctl. Instead, just decrement the reference.
[1] https://pubs.opengroup.org/onlinepubs/7908799/xsh/mmap.html
