From: Boris Brezillon <boris.brezillon@collabora.com>
To: Philipp Stanner <phasta@kernel.org>
Cc: "Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
"Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>,
"André Draszik" <andre.draszik@linaro.org>,
"Danilo Krummrich" <dakr@kernel.org>,
"Gary Guo" <gary@garyguo.net>,
"Paul E . McKenney" <paulmck@kernel.org>,
"Boqun Feng" <boqun@kernel.org>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v2] dma-buf: dma-fence: Fix potential NULL pointer dereference
Date: Mon, 29 Jun 2026 10:41:12 +0200 [thread overview]
Message-ID: <20260629104112.72d58bf5@fedora-2.home> (raw)
In-Reply-To: <20260629075636.2513214-2-phasta@kernel.org>
On Mon, 29 Jun 2026 09:56:37 +0200
Philipp Stanner <phasta@kernel.org> wrote:
> The commit mentioned in the fixes tag below introduced a mechanism
> through which fence producers can fully decouple from fence consumers.
> This, desirable, mechanism is based on the fence's signaled-bit as the
> "decoupling point".
>
> A sophisticated interaction between RCU and atomic instructions attempts
> to ensure that fence consumers can still interact with fence producers
> through the dma_fence_ops (callback pointers into the producer).
>
> This is the desired behavior: to check for decoupling, the signaled-bit
> is first checked. If it's not yet signaled, RCU ensures that the ops
> pointer cannot yet be NULL.
>
> Hereby, dma_fence_signal_timestamp_locked() first sets the signaled-bit,
> and then sets the ops pointer to NULL. Readers first load the ops
> pointer, and then check through the signaled-bit whether the pointer can
> legally be accessed.
>
> These set and load operations could occur out of order on weakly ordered
> platforms. This problem can be solved very elegantly by using the ops
> pointer itself as the synchronization point. The pointer is either NULL,
> or cannot become NULL while it is being used thanks to RCU.
>
> Replace the signaled-bit check in dma_fence_timeline_name() and
> dma_fence_driver_name().
>
> Cc: stable@vger.kernel.org
> Fixes: f4cc3ab824d6 ("dma-buf: protected fence ops by RCU v8")
> Signed-off-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> Changes since v1:
> - Use ops pointer instead of memory barriers. (Christian)
> - Rephrase commit message.
> ---
> drivers/dma-buf/dma-fence.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index c7ea1e75d38a..0a025dfdf131 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -1170,7 +1170,7 @@ const char __rcu *dma_fence_driver_name(struct dma_fence *fence)
>
> /* RCU protection is required for safe access to returned string */
> ops = rcu_dereference(fence->ops);
> - if (!dma_fence_test_signaled_flag(fence))
> + if (ops)
> return (const char __rcu *)ops->get_driver_name(fence);
> else
> return (const char __rcu *)"detached-driver";
> @@ -1203,7 +1203,7 @@ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence)
>
> /* RCU protection is required for safe access to returned string */
> ops = rcu_dereference(fence->ops);
> - if (!dma_fence_test_signaled_flag(fence))
> + if (ops)
> return (const char __rcu *)ops->get_driver_name(fence);
> else
> return (const char __rcu *)"signaled-timeline";
>
> base-commit: cdeb2ccd993ed8647adbbda2c3b103aa717fd6f7
next prev parent reply other threads:[~2026-06-29 8:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 7:56 [PATCH v2] dma-buf: dma-fence: Fix potential NULL pointer dereference Philipp Stanner
2026-06-29 8:41 ` Boris Brezillon [this message]
2026-06-29 8:49 ` Christian König
2026-06-29 10:43 ` Philipp Stanner
2026-06-29 11:25 ` Christian König
2026-06-29 9:10 ` 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=20260629104112.72d58bf5@fedora-2.home \
--to=boris.brezillon@collabora.com \
--cc=andre.draszik@linaro.org \
--cc=boqun@kernel.org \
--cc=christian.koenig@amd.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=phasta@kernel.org \
--cc=stable@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