From: Jason Gunthorpe <jgg@ziepe.ca>
To: Edward Srouji <edwards@nvidia.com>
Cc: "Leon Romanovsky" <leon@kernel.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org,
"Yishai Hadas" <yishaih@nvidia.com>
Subject: Re: [PATCH rdma-next 1/2] RDMA/uverbs: Add DMABUF object type and operations
Date: Tue, 20 Jan 2026 14:15:20 -0400 [thread overview]
Message-ID: <20260120181520.GS961572@ziepe.ca> (raw)
In-Reply-To: <20260108-dmabuf-export-v1-1-6d47d46580d3@nvidia.com>
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..
> diff --git a/drivers/infiniband/core/rdma_core.c b/drivers/infiniband/core/rdma_core.c
> index 18918f463361..3e0a8b9cd288 100644
> --- a/drivers/infiniband/core/rdma_core.c
> +++ b/drivers/infiniband/core/rdma_core.c
> @@ -465,7 +465,7 @@ alloc_begin_fd_uobject(const struct uverbs_api_object *obj,
>
> fd_type =
> container_of(obj->type_attrs, struct uverbs_obj_fd_type, type);
> - if (WARN_ON(fd_type->fops->release != &uverbs_uobject_fd_release &&
> + if (WARN_ON(fd_type->fops && fd_type->fops->release != &uverbs_uobject_fd_release &&
> fd_type->fops->release != &uverbs_async_event_release)) {
> ret = ERR_PTR(-EINVAL);
> goto err_fd;
> @@ -477,14 +477,16 @@ alloc_begin_fd_uobject(const struct uverbs_api_object *obj,
> goto err_fd;
> }
>
> - /* Note that uverbs_uobject_fd_release() is called during abort */
> - filp = anon_inode_getfile(fd_type->name, fd_type->fops, NULL,
> - fd_type->flags);
> - if (IS_ERR(filp)) {
> - ret = ERR_CAST(filp);
> - goto err_getfile;
> + if (fd_type->fops) {
> + /* Note that uverbs_uobject_fd_release() is called during abort */
> + filp = anon_inode_getfile(fd_type->name, fd_type->fops, NULL,
> + fd_type->flags);
> + if (IS_ERR(filp)) {
> + ret = ERR_CAST(filp);
> + goto err_getfile;
> + }
> + uobj->object = filp;
> }
> - uobj->object = filp;
>
> uobj->id = new_fd;
> return uobj;
> @@ -561,7 +563,9 @@ static void alloc_abort_fd_uobject(struct ib_uobject *uobj)
> {
> struct file *filp = uobj->object;
>
> - fput(filp);
> + if (filp)
> + fput(filp);
> +
> put_unused_fd(uobj->id);
This stuff changing hw the uobjects work should probably be in its own
patch with its own explanation about creating a uobject that wrappers
an externally allocated file descriptor vs this automatic internal
allocation.
> index 797e2fcc8072..66287e8e7ad7 100644
> --- a/drivers/infiniband/core/uverbs.h
> +++ b/drivers/infiniband/core/uverbs.h
> @@ -133,6 +133,16 @@ struct ib_uverbs_completion_event_file {
> struct ib_uverbs_event_queue ev_queue;
> };
>
> +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?
> +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
This should also eventually call the new revoke testing function Leon
is adding
Jason
next prev parent reply other threads:[~2026-01-20 18:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-08 11:11 [PATCH rdma-next 0/2] RDMA: Add support for exporting dma-buf file descriptors Edward Srouji
2026-01-08 11:11 ` [PATCH rdma-next 1/2] RDMA/uverbs: Add DMABUF object type and operations Edward Srouji
2026-01-20 18:15 ` Jason Gunthorpe [this message]
2026-01-21 8:32 ` Leon Romanovsky
2026-01-21 13:56 ` Jason Gunthorpe
2026-01-21 16:27 ` Yishai Hadas
2026-01-21 10:07 ` Yishai Hadas
2026-01-25 14:31 ` Leon Romanovsky
2026-01-08 11:11 ` [PATCH rdma-next 2/2] RDMA/mlx5: Implement DMABUF export ops Edward Srouji
2026-01-20 18:18 ` Jason Gunthorpe
2026-01-21 10:35 ` Yishai Hadas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260120181520.GS961572@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=edwards@nvidia.com \
--cc=leon@kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=yishaih@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.