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