On Wed, Jan 21, 2026 at 03:15:46PM +0100, Christian König wrote:
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.
Someone knowledgeable needs to document this properly, either in the code or in the official documentation. A cover letter is not the right place for subtle design decisions.
Thanks
Regards, Christian.
Jason