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 >
