[PATCH] dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD

[PATCH] dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD

[Val Packett]

Introduce a new ioctl that allows userspace to register an eventfd to get
notified when a dma-buf is released.

The current use case comes from virtio-gpu device backends wishing to add
support for guest-owned buffers with host handles (CREATE_GUEST_HANDLE):

* guest creates a guest-only blob resource on the virtgpu
* host creates a udmabuf from the iovecs sent by the guest
* guest attaches the resource to a cross-domain socket send operation
* guest immediately releases the resource (no longer needed by the guest)
* host sends the udmabuf to the compositor, but needs to delay responding
  to the resource release request until the resource is *actually* free
  on the host side, i.e. the compositor no longer uses it

Signed-off-by: Val Packett <val@invisiblethingslab.com>
---

More background on the use case with extra links:
https://lore.kernel.org/virtio-comment/20260903021442.423274-1-val@invisiblethingslab.com/

Funnily enough, gntdev-dmabuf (which is used on Xen hosts instead of
udmabuf for this) offers "a way" to "poll" for these release events
on its dmabufs (IOCTL_GNTDEV_DMABUF_EXP_WAIT_RELEASED), but it's unusable:

* it's a blocking wait!!
* release does not happen while you still have the fd open, so:
  * you can't just timeout and restart, you'd need the fd to restart;
  * and the only way to even close the fd is from a different thread,
    after some arbitrary timeout when hopefully the wait has started.

The buffer lifecycle coordination we need this for applies to KVM as well
and it generally doesn't make sense to have this as a provider-specific
thing since it's not related to the provider in any way, it's just
something we want from dmabufs in general.

Thanks,
~val

---
 drivers/dma-buf/dma-buf.c    | 24 ++++++++++++++++++++++++
 include/linux/dma-buf.h      |  3 +++
 include/uapi/linux/dma-buf.h |  1 +
 3 files changed, 28 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 36cdc342627e..1321fee73656 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -17,6 +17,7 @@
 #include <linux/dma-fence.h>
 #include <linux/dma-fence-unwrap.h>
 #include <linux/anon_inodes.h>
+#include <linux/eventfd.h>
 #include <linux/export.h>
 #include <linux/debugfs.h>
 #include <linux/list.h>
@@ -185,6 +186,11 @@ static void dma_buf_release(struct dentry *dentry)
 	if (dmabuf->resv == (struct dma_resv *)&dmabuf[1])
 		dma_resv_fini(dmabuf->resv);
 
+	if (dmabuf->release_eventfd) {
+		eventfd_signal(dmabuf->release_eventfd);
+		eventfd_ctx_put(dmabuf->release_eventfd);
+	}
+
 	WARN_ON(!list_empty(&dmabuf->attachments));
 	module_put(dmabuf->owner);
 	kfree(dmabuf->name);
@@ -537,6 +543,21 @@ static long dma_buf_import_sync_file(struct dma_buf *dmabuf,
 }
 #endif
 
+static long dma_buf_set_release_eventfd(struct dma_buf *dmabuf,
+					u32 fd)
+{
+	struct eventfd_ctx *ev_fd_ctx = eventfd_ctx_fdget(fd);
+
+	if (IS_ERR(ev_fd_ctx))
+		return PTR_ERR(ev_fd_ctx);
+
+	if (dmabuf->release_eventfd)
+		eventfd_ctx_put(dmabuf->release_eventfd);
+
+	dmabuf->release_eventfd = ev_fd_ctx;
+	return 0;
+}
+
 static long dma_buf_ioctl(struct file *file,
 			  unsigned int cmd, unsigned long arg)
 {
@@ -587,6 +608,9 @@ static long dma_buf_ioctl(struct file *file,
 		return dma_buf_import_sync_file(dmabuf, (const void __user *)arg);
 #endif
 
+	case DMA_BUF_IOCTL_SET_RELEASE_EVENTFD:
+		return dma_buf_set_release_eventfd(dmabuf, (u32)arg);
+
 	default:
 		return -ENOTTY;
 	}
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index d15b2b31d3c9..07b4a589a793 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -429,6 +429,9 @@ struct dma_buf {
 
 		__poll_t active;
 	} cb_in, cb_out;
+
+	/** @release_eventfd: for userspace release notification */
+	struct eventfd_ctx *release_eventfd;
 };
 
 /**
diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
index e827c9d20c5d..566dea778ad0 100644
--- a/include/uapi/linux/dma-buf.h
+++ b/include/uapi/linux/dma-buf.h
@@ -179,5 +179,6 @@ struct dma_buf_import_sync_file {
 #define DMA_BUF_SET_NAME_B	_IOW(DMA_BUF_BASE, 1, __u64)
 #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE	_IOWR(DMA_BUF_BASE, 2, struct dma_buf_export_sync_file)
 #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE	_IOW(DMA_BUF_BASE, 3, struct dma_buf_import_sync_file)
+#define DMA_BUF_IOCTL_SET_RELEASE_EVENTFD	_IOW(DMA_BUF_BASE, 4, __u32)
 
 #endif
-- 
2.55.0

Re: [PATCH] dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] dma-buf: race in dma_buf_set_release_eventfd() causes eventfd UAF and leak
- [Medium] dma-buf: ioctl argument type mismatch in dma_buf_ioctl()
- [Medium] dma-buf: single overwritable release_eventfd allows disarming notifications
--

commit 006342891462f158abfae40fb1d0a9db415351f4
Author: Val Packett <val@invisiblethingslab.com>

dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD

This commit introduces the DMA_BUF_IOCTL_SET_RELEASE_EVENTFD ioctl so
userspace can register an eventfd context to be signaled when a dma-buf
is released.

> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 36cdc342627ee..f6437a4e9284b 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
[ ... ]
> @@ -185,6 +186,11 @@ static void dma_buf_release(struct dentry *dentry)
>  	if (dmabuf->resv == (struct dma_resv *)&dmabuf[1])
>  		dma_resv_fini(dmabuf->resv);
>  
> +	if (dmabuf->release_eventfd) {
> +		eventfd_signal(dmabuf->release_eventfd);
> +		eventfd_ctx_put(dmabuf->release_eventfd);
> +	}
> +
>  	WARN_ON(!list_empty(&dmabuf->attachments));
>  	module_put(dmabuf->owner);
>  	kfree(dmabuf->name);
> @@ -537,6 +543,21 @@ static long dma_buf_import_sync_file(struct dma_buf *dmabuf,
>  }
>  #endif
>  
> +static long dma_buf_set_release_eventfd(struct dma_buf *dmabuf,
> +					u32 fd)
> +{
> +	struct eventfd_ctx *ev_fd_ctx = eventfd_ctx_fdget(fd);
> +
> +	if (IS_ERR(ev_fd_ctx))
> +		return PTR_ERR(ev_fd_ctx);
> +
> +	if (dmabuf->release_eventfd)
> +		eventfd_ctx_put(dmabuf->release_eventfd);
> +
> +	dmabuf->release_eventfd = ev_fd_ctx;
> +	return 0;
> +}

[Severity: Critical]
Can concurrent DMA_BUF_IOCTL_SET_RELEASE_EVENTFD calls on the same dma-buf
race in dma_buf_set_release_eventfd() in drivers/dma-buf/dma-buf.c and cause
a use-after-free or leak of struct eventfd_ctx?

dma_buf_ioctl() runs from .unlocked_ioctl without holding a lock and calls
dma_buf_set_release_eventfd(). Unlike dma_buf_set_name(), which serializes
updates with dmabuf->name_lock, dma_buf_set_release_eventfd() reads, puts,
and overwrites dmabuf->release_eventfd without locking or an atomic exchange:

Thread 1                                Thread 2
dma_buf_ioctl()                         dma_buf_ioctl()
  dma_buf_set_release_eventfd()           dma_buf_set_release_eventfd()
    if (dmabuf->release_eventfd)            if (dmabuf->release_eventfd)
      eventfd_ctx_put(release_eventfd);       eventfd_ctx_put(release_eventfd);
    dmabuf->release_eventfd = ctx1;         dmabuf->release_eventfd = ctx2;

If dmabuf->release_eventfd is already set, both threads can observe the same
old pointer and call eventfd_ctx_put() on it twice, underflowing its reference
count and leading to a use-after-free when the eventfd is later signaled in
dma_buf_release() or closed.

Similarly, if Thread 1 assigns dmabuf->release_eventfd = ctx1 after Thread 2
has already checked dmabuf->release_eventfd, Thread 2 will overwrite ctx1
with ctx2 without calling eventfd_ctx_put(ctx1), leaking the ctx1 reference
acquired by eventfd_ctx_fdget().

Should dmabuf->release_eventfd updates be synchronized with a lock or
xchg()?

> +
>  static long dma_buf_ioctl(struct file *file,
>  			  unsigned int cmd, unsigned long arg)
>  {
> @@ -587,6 +608,9 @@ static long dma_buf_ioctl(struct file *file,
>  		return dma_buf_import_sync_file(dmabuf, (const void __user *)arg);
>  #endif
>  
> +	case DMA_BUF_IOCTL_SET_RELEASE_EVENTFD:
> +		return dma_buf_set_release_eventfd(dmabuf, (u32)arg);
> +
>  	default:
>  		return -ENOTTY;
>  	}
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index d15b2b31d3c91..07b4a589a7935 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -429,6 +429,9 @@ struct dma_buf {
>  
>  		__poll_t active;
>  	} cb_in, cb_out;
> +
> +	/** @release_eventfd: for userspace release notification */
> +	struct eventfd_ctx *release_eventfd;
>  };

[Severity: Medium]
What happens if more than one process registers a release eventfd on the
same struct dma_buf, or if a recipient of the dma-buf fd calls
DMA_BUF_IOCTL_SET_RELEASE_EVENTFD?

Because struct dma_buf in include/linux/dma-buf.h stores a single
release_eventfd pointer and dma_buf_set_release_eventfd() in
drivers/dma-buf/dma-buf.c drops and replaces any existing context:

	if (dmabuf->release_eventfd)
		eventfd_ctx_put(dmabuf->release_eventfd);

	dmabuf->release_eventfd = ev_fd_ctx;

if a host backend registers an eventfd and then passes the dma-buf file
descriptor over a socket to another process (such as a compositor or client)
that also invokes DMA_BUF_IOCTL_SET_RELEASE_EVENTFD, the first eventfd_ctx
is released via eventfd_ctx_put() without ever being signaled by
dma_buf_release().

Could that leave the original waiter blocked indefinitely waiting for buffer
release, and would a list of registered eventfd contexts (or rejecting
re-registration) avoid allowing one holder to disarm another's notification?

>  
>  /**
> diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> index e827c9d20c5d3..566dea778ad06 100644
> --- a/include/uapi/linux/dma-buf.h
> +++ b/include/uapi/linux/dma-buf.h
> @@ -179,5 +179,6 @@ struct dma_buf_import_sync_file {
>  #define DMA_BUF_SET_NAME_B	_IOW(DMA_BUF_BASE, 1, __u64)
>  #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE	_IOWR(DMA_BUF_BASE, 2, struct dma_buf_export_sync_file)
>  #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE	_IOW(DMA_BUF_BASE, 3, struct dma_buf_import_sync_file)
> +#define DMA_BUF_IOCTL_SET_RELEASE_EVENTFD	_IOW(DMA_BUF_BASE, 4, __u32)

[Severity: Medium]
Is DMA_BUF_IOCTL_SET_RELEASE_EVENTFD in include/uapi/linux/dma-buf.h intended
to take a user pointer to __u32 or a file descriptor value directly?

Here DMA_BUF_IOCTL_SET_RELEASE_EVENTFD is defined with _IOW(DMA_BUF_BASE, 4,
__u32), which indicates a user pointer argument, and dma_buf_fops in
drivers/dma-buf/dma-buf.c uses compat_ptr_ioctl:

static const struct file_operations dma_buf_fops = {
	...
	.unlocked_ioctl	= dma_buf_ioctl,
	.compat_ioctl	= compat_ptr_ioctl,
	...
};

However, dma_buf_ioctl() in drivers/dma-buf/dma-buf.c casts arg directly by
value instead of copying from a user pointer:

	case DMA_BUF_IOCTL_SET_RELEASE_EVENTFD:
		return dma_buf_set_release_eventfd(dmabuf, (u32)arg);

Callers or language bindings following the _IOW(..., __u32) definition and
passing a pointer to a __u32 will have the truncated pointer address treated
as the file descriptor, while passing an integer by value conflicts with
compat_ptr_ioctl(). Should dma_buf_ioctl() read the descriptor via
get_user() / copy_from_user() to match the _IOW(..., __u32) definition?

>  
>  #endif

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261021093533.1990028-1-val@invisiblethingslab.com?part=1

Re: [PATCH] dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD

[Val Packett]

On 10/21/26 6:47 AM, sashiko-bot@kernel.org wrote:
> [..]
> Can concurrent DMA_BUF_IOCTL_SET_RELEASE_EVENTFD calls on the same dma-buf
> race in dma_buf_set_release_eventfd() in drivers/dma-buf/dma-buf.c and cause
> a use-after-free or leak of struct eventfd_ctx?
> [..]
> What happens if more than one process registers a release eventfd on the
> same struct dma_buf, or if a recipient of the dma-buf fd calls
> DMA_BUF_IOCTL_SET_RELEASE_EVENTFD? [..]
> Could that leave the original waiter blocked indefinitely waiting for buffer
> release, and would a list of registered eventfd contexts (or rejecting
> re-registration) avoid allowing one holder to disarm another's notification?

Yeeeeeah I guess a "one use only" policy would be better after all, i.e. 
not allowing replacement. That should solve both of these. I'll probably 
change it to that in v2.

>>   /**
>> diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
>> index e827c9d20c5d3..566dea778ad06 100644
>> --- a/include/uapi/linux/dma-buf.h
>> +++ b/include/uapi/linux/dma-buf.h
>> @@ -179,5 +179,6 @@ struct dma_buf_import_sync_file {
>>   #define DMA_BUF_SET_NAME_B	_IOW(DMA_BUF_BASE, 1, __u64)
>>   #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE	_IOWR(DMA_BUF_BASE, 2, struct dma_buf_export_sync_file)
>>   #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE	_IOW(DMA_BUF_BASE, 3, struct dma_buf_import_sync_file)
>> +#define DMA_BUF_IOCTL_SET_RELEASE_EVENTFD	_IOW(DMA_BUF_BASE, 4, __u32)
> [Severity: Medium]
> Is DMA_BUF_IOCTL_SET_RELEASE_EVENTFD in include/uapi/linux/dma-buf.h intended
> to take a user pointer to __u32 or a file descriptor value directly?
>
> Here DMA_BUF_IOCTL_SET_RELEASE_EVENTFD is defined with _IOW(DMA_BUF_BASE, 4,
> __u32), which indicates a user pointer argument [..]

I don't see anything in include/uapi/asm-generic/ioctl.h intended for 
defining value arguments but it's a common thing across the tree..?? :/


~val

Re: [PATCH] dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD

[Christian König]

On 10/21/26 11:08, Val Packett wrote:
> Introduce a new ioctl that allows userspace to register an eventfd to get
> notified when a dma-buf is released.
> 
> The current use case comes from virtio-gpu device backends wishing to add
> support for guest-owned buffers with host handles (CREATE_GUEST_HANDLE):
> 
> * guest creates a guest-only blob resource on the virtgpu
> * host creates a udmabuf from the iovecs sent by the guest
> * guest attaches the resource to a cross-domain socket send operation
> * guest immediately releases the resource (no longer needed by the guest)
> * host sends the udmabuf to the compositor, but needs to delay responding
>   to the resource release request until the resource is *actually* free
>   on the host side, i.e. the compositor no longer uses it

Interesting use case you have here.

It doesn't sound to crazy, e.g. it can't deadlock the kernel or anything like that which we often see with dma-fence.

> Signed-off-by: Val Packett <val@invisiblethingslab.com>
> ---
> 
> More background on the use case with extra links:
> https://lore.kernel.org/virtio-comment/20260903021442.423274-1-val@invisiblethingslab.com/
> 
> Funnily enough, gntdev-dmabuf (which is used on Xen hosts instead of
> udmabuf for this) offers "a way" to "poll" for these release events
> on its dmabufs (IOCTL_GNTDEV_DMABUF_EXP_WAIT_RELEASED), but it's unusable:
> 
> * it's a blocking wait!!
> * release does not happen while you still have the fd open, so:
>   * you can't just timeout and restart, you'd need the fd to restart;
>   * and the only way to even close the fd is from a different thread,
>     after some arbitrary timeout when hopefully the wait has started.

Oh that made my day :D

> The buffer lifecycle coordination we need this for applies to KVM as well
> and it generally doesn't make sense to have this as a provider-specific
> thing since it's not related to the provider in any way, it's just
> something we want from dmabufs in general.

I wouldn't put that on the DMA-buf file descriptor where basically anybody can mess with it. That is just an recipe for trouble.

The better approach seems to be putting it into the udmabuf_ioctl(), so that from the very beginning you add the eventfd which signals when the udmabuf is released.

If we need that for more implementations than just udmabuf, we can potentially add it to dma_buf_export_info so that exporters can provide the eventfd file descriptor directly on creation.

Regards,
Christian.

> 
> Thanks,
> ~val
> 
> ---
>  drivers/dma-buf/dma-buf.c    | 24 ++++++++++++++++++++++++
>  include/linux/dma-buf.h      |  3 +++
>  include/uapi/linux/dma-buf.h |  1 +
>  3 files changed, 28 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 36cdc342627e..1321fee73656 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -17,6 +17,7 @@
>  #include <linux/dma-fence.h>
>  #include <linux/dma-fence-unwrap.h>
>  #include <linux/anon_inodes.h>
> +#include <linux/eventfd.h>
>  #include <linux/export.h>
>  #include <linux/debugfs.h>
>  #include <linux/list.h>
> @@ -185,6 +186,11 @@ static void dma_buf_release(struct dentry *dentry)
>  	if (dmabuf->resv == (struct dma_resv *)&dmabuf[1])
>  		dma_resv_fini(dmabuf->resv);
>  
> +	if (dmabuf->release_eventfd) {
> +		eventfd_signal(dmabuf->release_eventfd);
> +		eventfd_ctx_put(dmabuf->release_eventfd);
> +	}
> +
>  	WARN_ON(!list_empty(&dmabuf->attachments));
>  	module_put(dmabuf->owner);
>  	kfree(dmabuf->name);
> @@ -537,6 +543,21 @@ static long dma_buf_import_sync_file(struct dma_buf *dmabuf,
>  }
>  #endif
>  
> +static long dma_buf_set_release_eventfd(struct dma_buf *dmabuf,
> +					u32 fd)
> +{
> +	struct eventfd_ctx *ev_fd_ctx = eventfd_ctx_fdget(fd);
> +
> +	if (IS_ERR(ev_fd_ctx))
> +		return PTR_ERR(ev_fd_ctx);
> +
> +	if (dmabuf->release_eventfd)
> +		eventfd_ctx_put(dmabuf->release_eventfd);
> +
> +	dmabuf->release_eventfd = ev_fd_ctx;
> +	return 0;
> +}
> +
>  static long dma_buf_ioctl(struct file *file,
>  			  unsigned int cmd, unsigned long arg)
>  {
> @@ -587,6 +608,9 @@ static long dma_buf_ioctl(struct file *file,
>  		return dma_buf_import_sync_file(dmabuf, (const void __user *)arg);
>  #endif
>  
> +	case DMA_BUF_IOCTL_SET_RELEASE_EVENTFD:
> +		return dma_buf_set_release_eventfd(dmabuf, (u32)arg);
> +
>  	default:
>  		return -ENOTTY;
>  	}
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index d15b2b31d3c9..07b4a589a793 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -429,6 +429,9 @@ struct dma_buf {
>  
>  		__poll_t active;
>  	} cb_in, cb_out;
> +
> +	/** @release_eventfd: for userspace release notification */
> +	struct eventfd_ctx *release_eventfd;
>  };
>  
>  /**
> diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> index e827c9d20c5d..566dea778ad0 100644
> --- a/include/uapi/linux/dma-buf.h
> +++ b/include/uapi/linux/dma-buf.h
> @@ -179,5 +179,6 @@ struct dma_buf_import_sync_file {
>  #define DMA_BUF_SET_NAME_B	_IOW(DMA_BUF_BASE, 1, __u64)
>  #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE	_IOWR(DMA_BUF_BASE, 2, struct dma_buf_export_sync_file)
>  #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE	_IOW(DMA_BUF_BASE, 3, struct dma_buf_import_sync_file)
> +#define DMA_BUF_IOCTL_SET_RELEASE_EVENTFD	_IOW(DMA_BUF_BASE, 4, __u32)
>  
>  #endif

Re: [PATCH] dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD

[Val Packett]

On 10/21/26 10:43 AM, Christian König wrote:
> [..]
>> The buffer lifecycle coordination we need this for applies to KVM as well
>> and it generally doesn't make sense to have this as a provider-specific
>> thing since it's not related to the provider in any way, it's just
>> something we want from dmabufs in general.
> I wouldn't put that on the DMA-buf file descriptor where basically anybody can mess with it. That is just an recipe for trouble.
>
> The better approach seems to be putting it into the udmabuf_ioctl(), so that from the very beginning you add the eventfd which signals when the udmabuf is released.
>
> If we need that for more implementations than just udmabuf, we can potentially add it to dma_buf_export_info so that exporters can provide the eventfd file descriptor directly on creation.

Well, we already need it with both udmabuf and gntdev-dmabuf..

Involving the exporter sounds really annoying when it's not something 
exporter dependent really.. What if the policy is just "only one eventfd 
ever" i.e. the first call of the ioctl succeeds but later calls on the 
same dmabuf return an error? That should remove the concern about one 
user messing with another's events (and avoid the concurrent replacement 
issue sashiko-bot warned about)..

Thanks,
~val

Re: [PATCH] dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD

[Christian König]

On 10/21/26 22:16, Val Packett wrote:
> 
> On 10/21/26 10:43 AM, Christian König wrote:
>> [..]
>>> The buffer lifecycle coordination we need this for applies to KVM as well
>>> and it generally doesn't make sense to have this as a provider-specific
>>> thing since it's not related to the provider in any way, it's just
>>> something we want from dmabufs in general.
>> I wouldn't put that on the DMA-buf file descriptor where basically anybody can mess with it. That is just an recipe for trouble.
>>
>> The better approach seems to be putting it into the udmabuf_ioctl(), so that from the very beginning you add the eventfd which signals when the udmabuf is released.
>>
>> If we need that for more implementations than just udmabuf, we can potentially add it to dma_buf_export_info so that exporters can provide the eventfd file descriptor directly on creation.
> 
> Well, we already need it with both udmabuf and gntdev-dmabuf..
> 
> Involving the exporter sounds really annoying when it's not something exporter dependent really.. What if the policy is just "only one eventfd ever" i.e. the first call of the ioctl succeeds but later calls on the same dmabuf return an error?

No, exactly that is what I'm trying to avoid.

Nobody except the original creater should be able to insert an eventfd here.

Regards,
Christian.

> That should remove the concern about one user messing with another's events (and avoid the concurrent replacement issue sashiko-bot warned about)..
> 
> Thanks,
> ~val
> 

Re: [PATCH] dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD

[Val Packett]

On 10/22/26 9:26 AM, Christian König wrote:
> On 10/21/26 22:16, Val Packett wrote:
>> On 10/21/26 10:43 AM, Christian König wrote:
>>> [..]
>>>> The buffer lifecycle coordination we need this for applies to KVM as well
>>>> and it generally doesn't make sense to have this as a provider-specific
>>>> thing since it's not related to the provider in any way, it's just
>>>> something we want from dmabufs in general.
>>> I wouldn't put that on the DMA-buf file descriptor where basically anybody can mess with it. That is just an recipe for trouble.
>>>
>>> The better approach seems to be putting it into the udmabuf_ioctl(), so that from the very beginning you add the eventfd which signals when the udmabuf is released.
>>>
>>> If we need that for more implementations than just udmabuf, we can potentially add it to dma_buf_export_info so that exporters can provide the eventfd file descriptor directly on creation.
>> Well, we already need it with both udmabuf and gntdev-dmabuf..
>>
>> Involving the exporter sounds really annoying when it's not something exporter dependent really.. What if the policy is just "only one eventfd ever" i.e. the first call of the ioctl succeeds but later calls on the same dmabuf return an error?
> No, exactly that is what I'm trying to avoid.
>
> Nobody except the original creater should be able to insert an eventfd here.

If there's no replacement allowed anymore, what could possibly be 
harmful/undesirable about "someone else" being able to do this?

With a "first caller only" policy, the original creator already can be 
100% sure that no one else is able to insert an eventfd:

If the original creator calls this API before sending the fd to anyone 
else, well, the original creator *is* the first caller, that's it.

Otherwise, i.e. if the original creator is not interested in this API.. 
it's unlikely a different process would use it, but if one does for some 
reason, I don't see any negative consequences from that?



Thanks,
~val

Re: [PATCH] dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD

[Christian König]

On 10/23/26 02:36, Val Packett wrote:
> On 10/22/26 9:26 AM, Christian König wrote:
>> On 10/21/26 22:16, Val Packett wrote:
>>> On 10/21/26 10:43 AM, Christian König wrote:
>>>> [..]
>>>>> The buffer lifecycle coordination we need this for applies to KVM as well
>>>>> and it generally doesn't make sense to have this as a provider-specific
>>>>> thing since it's not related to the provider in any way, it's just
>>>>> something we want from dmabufs in general.
>>>> I wouldn't put that on the DMA-buf file descriptor where basically anybody can mess with it. That is just an recipe for trouble.
>>>>
>>>> The better approach seems to be putting it into the udmabuf_ioctl(), so that from the very beginning you add the eventfd which signals when the udmabuf is released.
>>>>
>>>> If we need that for more implementations than just udmabuf, we can potentially add it to dma_buf_export_info so that exporters can provide the eventfd file descriptor directly on creation.
>>> Well, we already need it with both udmabuf and gntdev-dmabuf..
>>>
>>> Involving the exporter sounds really annoying when it's not something exporter dependent really.. What if the policy is just "only one eventfd ever" i.e. the first call of the ioctl succeeds but later calls on the same dmabuf return an error?
>> No, exactly that is what I'm trying to avoid.
>>
>> Nobody except the original creater should be able to insert an eventfd here.
> 
> If there's no replacement allowed anymore, what could possibly be harmful/undesirable about "someone else" being able to do this?
>
> With a "first caller only" policy, the original creator already can be 100% sure that no one else is able to insert an eventfd:

Ok that sounds like you my argumentation wasn't fully clear: That approach is exactly what I try to avoid!

> If the original creator calls this API before sending the fd to anyone else, well, the original creator *is* the first caller, that's it.
> 
> Otherwise, i.e. if the original creator is not interested in this API.. it's unlikely a different process would use it, but if one does for some reason, I don't see any negative consequences from that?

First of all if this gets added as common DMA-buf API the functionality suddenly becomes available to every exporter, not just the ones who explicitly implement it.

That in turn would be rather questionable because lifetime is something only the exporter of a buffer can fully deal with.

For example it is very common that the exporter delegates cleanup from the ->release callback to a work item and your whole approach with the eventfd on the DMA-buf then doesn't work any more.


Then second when the add this as common DMA-buf functionality then it should be usable by everybody and not just the first one who asks. Otherwise you can run into all kind mess with that when you give a DMA-buf where the eventfd slot is already used up to some other process which expects to use that functionality.


For now that functionality only seems to make sense for the original creator and a limited amount of exporters where it actually works. So my suggestion is to either add some functionality to the exporter(s) or add some common functionality to dma_buf_export_info to aid exporters with their implementation.

Apart from that the approach with the eventfd looks perfectly fine to me.

Regards,
Christian.

> 
> 
> 
> Thanks,
> ~val