On 1/21/26 14:59, Jason Gunthorpe wrote: > On Wed, Jan 21, 2026 at 02:52:53PM +0100, Christian König wrote: >> On 1/21/26 14:18, Jason Gunthorpe wrote: >>> On Wed, Jan 21, 2026 at 10:17:16AM +0100, Christian König wrote: >>>> The whole idea is to make invalidate_mappings truly optional. >>> >>> But it's not really optional! It's absence means we are ignoring UAF >>> security issues when the exporters do their move_notify() and nothing >>> happens. >> >> No that is unproblematic. >> >> See the invalidate_mappings callback just tells the importer that >> the mapping in question can't be relied on any more. >> >> But the mapping is truly freed only by the importer calling >> dma_buf_unmap_attachment(). >> >> In other words the invalidate_mappings give the signal to the >> importer to disable all operations and the >> dma_buf_unmap_attachment() is the signal from the importer that the >> housekeeping structures can be freed and the underlying address >> space or backing object re-used. > > I see > > Can we document this please, I haven't seen this scheme described > anyhwere. > > And let's clarify what I said in my other email that this new revoke > semantic is not just a signal to maybe someday unmap but a hard > barrier that it must be done once the fences complete, similar to > non-pinned importers.
Well, I would avoid that semantics. Even when the exporter requests the mapping to be invalidated it does not mean that the mapping can go away immediately. It's fine when accesses initiated after an invalidation and then waiting for fences go into nirvana and have undefined results, but they should not trigger PCI AER, warnings from the IOMMU or even worse end up in some MMIO BAR of a newly attached devices. So if the exporter wants to be 100% sure that nobody is using the mapping any more then it needs to wait for the importer to call dma_buf_unmap_attachment(). > The cover letter should be clarified with this understanding too. Yeah, completely agree. We really need to flash out that semantics in the documentation. Regards, Christian. > > Jason
