On Mon, Jan 26, 2026 at 08:38:44PM +0000, Pranjal Shrivastava wrote:

I noticed that Patch 5 removes the invalidate_mappings stub from umem_dmabuf.c, effectively making the callback NULL for an RDMA importer. Consequently, dma_buf_attach_revocable() (introduced here) will return false for these importers.

Yes, that is the intention.

Since the cover letter mentions that VFIO will use dma_buf_attach_revocable() to prevent unbounded waits, this appears to effectively block paths like the VFIO-export -> RDMA-import path..

It remains usable with the ODP path and people are using that right now.

Given that RDMA is a significant consumer of dma-bufs, are there plans to implement proper revocation support in the IB/RDMA core (umem_dmabuf)?

This depends on each HW, they need a way to implement the revoke semantic. I can't guess what is possible, but I would hope that most HW could at least do a revoke on a real MR.

Eg a MR rereg operation to a kernel owned empty PD is an effective "revoke", and MR rereg is at least defined by standards so HW should implement it.

It would be good to know if there's a plan for bringing such importers into compliance with the new revocation semantics so they can interop with VFIO OR are we completely ruling out users like RDMA / IB importing any DMABUFs exported by VFIO?

It will be driver dependent, there is no one shot update here.

Jason