On Mon, Apr 25, 2022 at 07:18:36AM -0700, Dave Hansen wrote: > On 4/25/22 06:53, Jean-Philippe Brucker wrote: > > On Sat, Apr 23, 2022 at 07:13:39PM +0800, zhangfei....@foxmail.com wrote: > >>>> On 5.17 > >>>> fops_release is called automatically, as well as iommu_sva_unbind_device. > >>>> On 5.18-rc1. > >>>> fops_release is not called, have to manually call close(fd) > >>> Right that's weird > >> Looks it is caused by the fix patch, via mmget, which may add refcount of > >> fd. > > Yes indirectly I think: when the process mmaps the queue, mmap_region() > > takes a reference to the uacce fd. That reference is released either by > > explicit close() or munmap(), or by exit_mmap() (which is triggered by > > mmput()). Since there is an mm->fd dependency, we cannot add a fd->mm > > dependency, so no mmget()/mmput() in bind()/unbind(). > > > > I guess we should go back to refcounted PASIDs instead, to avoid freeing > > them until unbind(). > > Yeah, this is a bit gnarly for -rc4. Let's just make sure there's > nothing else simple we can do. > > How does the IOMMU hardware know that all activity to a given PASID is > finished? That activity should, today, be independent of an mm or a > fd's lifetime.
In the case of uacce, it's tied to the fd lifetime: opening an accelerator queue calls iommu_sva_bind_device(), which sets up the PASID context in the IOMMU. Closing the queue calls iommu_sva_unbind_device() which destroys the PASID context (after the device driver stopped all DMA for this PASID). Thanks, Jean _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
