From: Philipp Stanner <phasta@kernel.org>
To: "Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
dakr@kernel.org
Cc: linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, Philipp Stanner <phasta@kernel.org>
Subject: [PATCH v2] dma-buf/dma-fence: Mark two callbacks as deprecated
Date: Mon, 12 Oct 2026 19:19:40 +0200 [thread overview]
Message-ID: <20261012171939.390365-2-phasta@kernel.org> (raw)
dma_fence's backend_ops functions ops->wait() and ops->release() are
problematic because they prevent fence producers from unloading.
Moreover, they can easily be implemented through simpler means more
aligned with the dma_fence contract.
Since the declared goal of dma_fence is to move towards an
implementation that supports driver-unload in all circumstances, we must
prevent more parties from implementing those callbacks.
Deprecate ops->release() and ops->wait() and document what users should
do instead.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
---
Changes in v2:
- Drop confusing sentence (Christian).
---
include/linux/dma-fence.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index dd07d128adc3..388c07d11e70 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -220,6 +220,8 @@ struct dma_fence_ops {
/**
* @wait:
*
+ * DEPRECATED!
+ *
* Custom wait implementation, defaults to dma_fence_default_wait() if
* not set.
*
@@ -243,6 +245,8 @@ struct dma_fence_ops {
/**
* @release:
*
+ * DEPRECATED!
+ *
* Called on destruction of fence to release additional resources.
* Can be called from irq context. This callback is optional. If it is
* NULL, then dma_fence_free() is instead called as the default
@@ -254,6 +258,12 @@ struct dma_fence_ops {
*
* If the callback is implemented the memory backing the dma_fence
* object must be freed RCU safe.
+ *
+ * Deprecated because it prevents the producer of a fence from
+ * unloading. No new users must be implemented. Parties with a
+ * hypothetical need for this callback can instead simply and directly
+ * perform their custom release operations one RCU grace period after
+ * they have signaled the fence.
*/
void (*release)(struct dma_fence *fence);
base-commit: 3e32932d3626d0279f9b3531bd648f8c0a16cb08
--
2.55.0
next reply other threads:[~2026-10-12 17:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 17:19 Philipp Stanner [this message]
2026-10-12 17:28 ` [PATCH v2] dma-buf/dma-fence: Mark two callbacks as deprecated sashiko-bot
2026-10-13 6:50 ` Christian König
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=20261012171939.390365-2-phasta@kernel.org \
--to=phasta@kernel.org \
--cc=christian.koenig@amd.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.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 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.