From: "Christian König" <christian.koenig@amd.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: phasta@mailbox.org, matthew.brost@intel.com,
sumit.semwal@linaro.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org
Subject: Re: [PATCH 2/8] dma-buf: detach fence ops on signal v2
Date: Thu, 19 Feb 2026 13:52:43 +0100 [thread overview]
Message-ID: <10fa03cc-6575-48ce-b2ff-401b6a8bf4ce@amd.com> (raw)
In-Reply-To: <20260213152257.2651e2bb@fedora>
On 2/13/26 15:22, Boris Brezillon wrote:
>> ---
>> drivers/dma-buf/dma-fence.c | 16 ++++++++++++----
>> include/linux/dma-fence.h | 4 ++--
>> 2 files changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
>> index de9bf18be3d4..ba02321bef0b 100644
>> --- a/drivers/dma-buf/dma-fence.c
>> +++ b/drivers/dma-buf/dma-fence.c
>> @@ -371,6 +371,14 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence,
>> &fence->flags)))
>> return;
>>
>> + /*
>> + * When neither a release nor a wait operation is specified set the ops
>> + * pointer to NULL to allow the fence structure to become independent
>> + * from who originally issued it.
>
> I think this deserves some comment in the dma_fence_ops doc, so that
> people know what to expect when they implement this interface.
There was already a warning added like ~5years ago that implementations shouldn't use the wait callback.
Completely independent of this patch set here we already had tons of trouble with it because it can't take into account when userpsace waits for multiple fences from different implementations.
It potentially was never a good idea to have in the first place, we basically only had it because radeon (and IIRC nouveau at that point) depended on it.
Regards,
Christian.
next prev parent reply other threads:[~2026-02-19 12:52 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-10 10:01 Independence for dma_fences! v7 Christian König
2026-02-10 10:01 ` [PATCH 1/8] dma-buf: protected fence ops by RCU v5 Christian König
2026-02-11 10:06 ` Philipp Stanner
2026-02-11 15:43 ` Christian König
2026-02-12 8:56 ` Philipp Stanner
2026-02-19 10:23 ` Christian König
2026-02-19 10:35 ` Philipp Stanner
2026-02-19 12:49 ` Christian König
2026-02-12 9:03 ` Tvrtko Ursulin
2026-02-12 9:31 ` Tvrtko Ursulin
2026-02-13 14:20 ` Boris Brezillon
2026-02-10 10:01 ` [PATCH 2/8] dma-buf: detach fence ops on signal v2 Christian König
2026-02-13 14:22 ` Boris Brezillon
2026-02-19 12:52 ` Christian König [this message]
2026-02-19 15:49 ` Boris Brezillon
2026-02-10 10:01 ` [PATCH 3/8] dma-buf: abstract fence locking v2 Christian König
2026-02-12 9:07 ` Tvrtko Ursulin
2026-02-10 10:01 ` [PATCH 4/8] dma-buf: inline spinlock for fence protection v4 Christian König
2026-02-11 9:50 ` Philipp Stanner
2026-02-11 14:59 ` Christian König
2026-02-12 9:01 ` Philipp Stanner
2026-02-12 9:16 ` Tvrtko Ursulin
2026-02-13 14:27 ` Boris Brezillon
2026-02-15 8:48 ` Boris Brezillon
2026-02-16 7:33 ` Philipp Stanner
2026-02-16 9:48 ` Boris Brezillon
2026-02-10 10:02 ` [PATCH 5/8] dma-buf/selftests: test RCU ops and inline lock v2 Christian König
2026-02-10 10:02 ` [PATCH 6/8] dma-buf: use inline lock for the stub fence v2 Christian König
2026-02-13 14:32 ` Boris Brezillon
2026-02-10 10:02 ` [PATCH 7/8] dma-buf: use inline lock for the dma-fence-array Christian König
2026-02-13 14:33 ` Boris Brezillon
2026-02-10 10:02 ` [PATCH 8/8] dma-buf: use inline lock for the dma-fence-chain Christian König
2026-02-13 14:33 ` Boris Brezillon
[not found] <20260219160822.1529-1-christian.koenig@amd.com>
2026-02-19 16:07 ` [PATCH 2/8] dma-buf: detach fence ops on signal v2 Christian König
2026-02-21 15:28 ` kernel test robot
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=10fa03cc-6575-48ce-b2ff-401b6a8bf4ce@amd.com \
--to=christian.koenig@amd.com \
--cc=boris.brezillon@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=matthew.brost@intel.com \
--cc=phasta@mailbox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.