Re: [PATCH] dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD

[Val Packett <val@invisiblethingslab.com>]

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