linux-kernel - Re: [PATCH rdma-next 1/2] RDMA/uverbs: Add DMABUF object type and operations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <919266de-f5d2-4f76-8c7f-1aeb55ad99cf@nvidia.com>
Date: Wed, 21 Jan 2026 12:07:56 +0200
From: Yishai Hadas <yishaih@...dia.com>
To: Jason Gunthorpe <jgg@...pe.ca>, Edward Srouji <edwards@...dia.com>
CC: Leon Romanovsky <leon@...nel.org>, Sumit Semwal <sumit.semwal@...aro.org>,
	Christian König <christian.koenig@....com>,
	<linux-kernel@...r.kernel.org>, <linux-rdma@...r.kernel.org>,
	<linux-media@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
	<linaro-mm-sig@...ts.linaro.org>
Subject: Re: [PATCH rdma-next 1/2] RDMA/uverbs: Add DMABUF object type and
 operations

On 20/01/2026 20:15, 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..

Sure, I'll add.

> 
> 
>> 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.

Sure, I’ll split the current patch into two patches.

> 
>> 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

Please see Leon's answer on that.

Yishai