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