On Tue, Jan 20, 2026 at 02:15:20PM -0400, Jason Gunthorpe wrote:
On Thu, Jan 08, 2026 at 01:11:14PM +0200, Edward Srouji wrote:
void rdma_user_mmap_entry_remove(struct rdma_user_mmap_entry *entry) {
- struct ib_uverbs_dmabuf_file *uverbs_dmabuf, *tmp;
- if (!entry) return;
- mutex_lock(&entry->dmabufs_lock); xa_lock(&entry->ucontext->mmap_xa); entry->driver_removed = true; xa_unlock(&entry->ucontext->mmap_xa);
- list_for_each_entry_safe(uverbs_dmabuf, tmp, &entry->dmabufs, dmabufs_elm) {
dma_resv_lock(uverbs_dmabuf->dmabuf->resv, NULL);list_del(&uverbs_dmabuf->dmabufs_elm);uverbs_dmabuf->revoked = true;dma_buf_move_notify(uverbs_dmabuf->dmabuf);dma_resv_unlock(uverbs_dmabuf->dmabuf->resv);This will need the same wait that Christian pointed out for VFIO..
Yes, something like this is missing https://lore.kernel.org/all/20260120-dmabuf-revoke-v3-6-b7e0b07b8214@nvidia....
<...>
+struct ib_uverbs_dmabuf_file {
- struct ib_uobject uobj;
- struct dma_buf *dmabuf;
- struct list_head dmabufs_elm;
- struct rdma_user_mmap_entry *mmap_entry;
- struct dma_buf_phys_vec phys_vec;
Oh, are we going to have weird merge conflicts with this Leon?
No, Alex created a shared branch with the rename already applied for me. I had planned to merge it into the RDMA tree before taking this series, and then update dma_buf_phys_vec to phys_vec locally.
+static int uverbs_dmabuf_attach(struct dma_buf *dmabuf,
struct dma_buf_attachment *attachment)+{
- struct ib_uverbs_dmabuf_file *priv = dmabuf->priv;
- if (!attachment->peer2peer)
return -EOPNOTSUPP;- if (priv->revoked)
return -ENODEV;This should only be checked in map
I disagree with word "only", the more accurate word is "too". There is no need to allow new importer attach if this exporter is marked as revoked.
This should also eventually call the new revoke testing function Leon is adding
We will add it once my series will be accepted.
Thanks
Jason