On Thu, 9 Apr 2020 09:08:21 -0300 Jason Gunthorpe <jgg@xxxxxxxx> wrote: > On Wed, Apr 08, 2020 at 04:48:02PM -0700, Jacob Pan wrote: > > > Yes, this is the proper way, when the DMA is stopped and no use > > > of the PASID remains then you can drop the mmu notifier and > > > release the PASID entirely. If that is linked to the lifetime of > > > the FD then forget completely about the mm_struct lifetime, it > > > doesn't matter.. > > Got everything above, thanks a lot. > > > > If everything is in order with the FD close. Why do we need to > > "ask IOMMU drivers to silently abort DMA and Page Requests in the > > meantime." in mm_exit notifier? This will be done orderly in unbind > > anyway. > > I thought this is exactly what Jean-Phillippe is removing here, it is > a bad idea for the reasons he explained. > I think this patch only removed driver side callbacks, i.e. to stop DMA. But not removing IOMMU side of stop DMA, PRS. Before uacce, (universal accelerator framework), sva bind/unbind is not guaranteed at open/close FD time. Therefore, mmu notifier is needed if mmexit comes without unbind. > > > > Enforcing unbind upon FD close might be a precarious path, > > > > perhaps that is why we have to deal with out of order > > > > situation? > > > > > > How so? You just put it in the FD release function :) > > > > I was thinking some driver may choose to defer unbind in some > > workqueue etc. > > Doesn't really change anything, the lifetime of the PASID wouuld be > the lifetime of the notifier and the bind, and DMA can't continue > without the notifier registered. > True, it is just better not to defer. Otherwise, the window of suppressing error gets longer.
