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. The cover letter should be clarified with this understanding too. Jason
