From: Val Packett <val@invisiblethingslab.com>
To: "Christian König" <christian.koenig@amd.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Philipp Stanner" <phasta@kernel.org>
Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] dma-buf: Add DMA_BUF_IOCTL_SET_RELEASE_EVENTFD
Date: Wed, 21 Oct 2026 17:16:54 -0300 [thread overview]
Message-ID: <a1057af1-2390-41c0-ac57-4ab9ef0fe31d@invisiblethingslab.com> (raw)
In-Reply-To: <6e45ae81-0319-4857-a96e-159509c1b140@amd.com>
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
prev parent reply other threads:[~2026-10-21 20:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 9:08 Val Packett
2026-10-21 13:43 ` Christian König
2026-10-21 20:16 ` Val Packett [this message]
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=a1057af1-2390-41c0-ac57-4ab9ef0fe31d@invisiblethingslab.com \
--to=val@invisiblethingslab.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=phasta@kernel.org \
--cc=sumit.semwal@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®