On Mon, Jan 19, 2026 at 11:56:16AM +0100, Christian König wrote:
On 1/18/26 13:08, Leon Romanovsky wrote:
From: Leon Romanovsky leonro@nvidia.com
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.
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.
For exporters, this means implementing the .pin() callback, which checks the DMA‑buf attachment for a valid revoke implementation.
Signed-off-by: Leon Romanovsky leonro@nvidia.com
include/linux/dma-buf.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
<...>
- Returns true if DMA-buf importer honors revoke semantics, which is
- negotiated with the exporter, by making sure that importer implements
- .invalidate_mappings() callback and calls to dma_buf_pin() after
- DMA-buf attach.
That wording is to unclear. Something like:
Returns true if the DMA-buf importer can handle invalidating it's mappings at any time, even after pinning a buffer.
<...>
That's clearly not a good name. But that is already discussed in another thread.
<...>
Oh, we should have renamed that as well. Or maybe it is time to completely remove that config option.
<...>
This is checking exporter and not importer capabilities, please drop.
<...>
So when invalidate_mappings is implemented we need to be able to call it at any time. Yeah that sounds like a valid approach to me.
But we need to remove the RDNA callback with the warning then to properly signal that. And also please document that in the callback kerneldoc.
Will do, thanks
Regards, Christian.
+}
struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, struct device *dev); struct dma_buf_attachment *