On Sun, Jan 18, 2026 at 03:29:02PM +0100, Thomas Hellström wrote: > On Sun, 2026-01-18 at 14:08 +0200, Leon Romanovsky wrote: > > From: Leon Romanovsky <[email protected]> > > > > Document a DMA-buf revoke mechanism that allows an exporter to > > explicitly > > invalidate ("kill") a shared buffer after it has been handed out to > > importers. Once revoked, all further CPU and device access is > > blocked, and > > importers consistently observe failure. > > See previous comment WRT this. > > > > > This requires both importers and exporters to honor the revoke > > contract. > > > > For importers, this means implementing .invalidate_mappings() and > > calling > > dma_buf_pin() after the DMA‑buf is attached to verify the exporter’s > > support > > for revocation. > > Why would the importer want to verify the exporter's support for > revocation? If the exporter doesn't support it, the only consequence > would be that invalidate_mappings() would never be called, and that > dma_buf_pin() is a NOP. Besides, dma_buf_pin() would not return an > error if the exporter doesn't implement the pin() callback?
The idea is that both should do revoke and there is a need to indicate that this exporter has some expectations from the importers. One of them is that invalidate_mappings exists. Thanks > > Or perhaps I missed a prereq patch? > > Thanks, > Thomas > >
