From: Philipp Stanner <phasta@kernel.org>
To: "Sumit Semwal" <sumit.semwal@linaro.org>,
"Gustavo Padovan" <gustavo@padovan.org>,
"Christian König" <christian.koenig@amd.com>,
"Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>
Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, Philipp Stanner <phasta@kernel.org>,
Danilo Krummrich <dakr@kernel.org>
Subject: [PATCH] dma-fence: Correct return of dma_fence_driver_name()
Date: Fri, 24 Oct 2025 09:50:18 +0200 [thread overview]
Message-ID: <20251024075019.162351-2-phasta@kernel.org> (raw)
To decouple the dma_fence_ops lifetime from dma_fences lifetime RCU
support was added to said function, coupled with using the signaled bit
to detect whether the fence_ops might be gone already.
When implementing that a wrong string was set as a default return
parameter, indicating that every driver whose fence is already signalled
must be detached, which is frankly wrong.
Reported-by: Danilo Krummrich <dakr@kernel.org>
Fixes: 506aa8b02a8d ("dma-fence: Add safe access helpers and document the rules")
Signed-off-by: Philipp Stanner <phasta@kernel.org>
---
When this was merged, it sadly slipped by me. I think this entire RCU
mechanism was / is an overengineered idea.
If we look at who actually uses dma_fence_driver_name() and
dma_fence_timeline_name() – functions from which the largest share of
the fence_ops vs. fence lifetime issue stems from – we discover that
there is a single user:
i915.
Isn't that driver even deprecated?
I think the better thing to do is: remove these functions alltogether,
or at least deprecate them. Then the only lifetime issue left so solve
is the callback functions.
P.
---
drivers/dma-buf/dma-fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 3f78c56b58dc..1875a0abebd3 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -1111,7 +1111,7 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence)
if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags))
return fence->ops->get_driver_name(fence);
else
- return "detached-driver";
+ return "driver-whose-fence-is-already-signalled";
}
EXPORT_SYMBOL(dma_fence_driver_name);
--
2.49.0
next reply other threads:[~2025-10-24 7:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 7:50 Philipp Stanner [this message]
2025-10-24 8:31 ` [PATCH] dma-fence: Correct return of dma_fence_driver_name() Tvrtko Ursulin
2025-10-24 10:59 ` Philipp Stanner
2025-10-24 11:31 ` Tvrtko Ursulin
2025-10-24 12:12 ` Danilo Krummrich
2025-10-24 12:40 ` Tvrtko Ursulin
2025-10-24 13:13 ` Danilo Krummrich
2025-10-24 13:37 ` Tvrtko Ursulin
2025-10-24 14:17 ` Danilo Krummrich
2025-10-24 14:28 ` Tvrtko Ursulin
2025-10-24 14:36 ` Danilo Krummrich
2025-10-24 16:06 ` Tvrtko Ursulin
2025-10-24 16:18 ` Danilo Krummrich
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=20251024075019.162351-2-phasta@kernel.org \
--to=phasta@kernel.org \
--cc=christian.koenig@amd.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo@padovan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=tvrtko.ursulin@igalia.com \
/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