From: sashiko-bot@kernel.org
To: "Philipp Stanner" <phasta@kernel.org>
Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
linux-trace-kernel@vger.kernel.org, media-ci@linuxtv.org,
ojeda@kernel.org, gary@garyguo.net
Subject: Re: [RFC PATCH v2 1/3] dma-fence: Remove RCU protection for fence->ops
Date: Tue, 20 Oct 2026 10:20:37 +0000 [thread overview]
Message-ID: <sashiko-outbox-178825@kernel.org> (raw)
In-Reply-To: <20261020100034.759183-3-phasta@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] dma-fence: broken KUnit test_signaling() after keeping fence->ops on signal
- [Low] dma-fence: sparse warnings from remaining rcu_access_pointer() on fence->ops
--
commit 4607587506fc5e0428c9d4ca148fc5a0c94b0003
Author: Philipp Stanner <phasta@kernel.org>
dma-fence: Remove RCU protection for fence->ops
This commit removes the RCU protection and __rcu annotation for
struct dma_fence::ops, and stops clearing fence->ops to NULL when
signaling fences without release or wait callbacks.
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index bd58688b81a72..5dab647e3f3f9 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -353,7 +353,6 @@ void __dma_fence_might_wait(void)
> void dma_fence_signal_timestamp_locked(struct dma_fence *fence,
> ktime_t timestamp)
> {
> - const struct dma_fence_ops *ops;
> struct dma_fence_cb *cur, *tmp;
> struct list_head cb_list;
>
> @@ -365,15 +364,6 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence,
>
> trace_dma_fence_signaled(fence);
>
> - /*
> - * 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.
> - */
> - ops = rcu_dereference_protected(fence->ops, true);
> - if (!ops->release && !ops->wait)
> - RCU_INIT_POINTER(fence->ops, NULL);
> -
[Severity: Medium]
Does keeping fence->ops set here break test_signaling() in
drivers/dma-buf/st-dma-fence.c?
In drivers/dma-buf/st-dma-fence.c, test_signaling() (added in commit
3695d754ffbb ("dma-buf/selftests: test RCU ops and inline lock v2"))
creates a mock fence using mock_ops (which defines neither .release nor
.wait), signals it via dma_fence_check_and_signal(), and then checks:
if (rcu_dereference_protected(f->ops, true)) {
KUNIT_FAIL(test, "Fence ops not cleared on signal");
goto err_free;
}
Since dma_fence_signal_timestamp_locked() no longer clears fence->ops to
NULL, won't this KUnit check unconditionally fail? Additionally, passing
the non-__rcu f->ops pointer to rcu_dereference_protected() there will
trigger a Sparse address-space warning.
> /* Stash the cb_list before replacing it with the timestamp */
> list_replace(&fence->cb_list, &cb_list);
>
[ ... ]
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index dd07d128adc3b..874848a4aec46 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -72,7 +72,7 @@ struct dma_fence {
> spinlock_t *extern_lock;
> spinlock_t inline_lock;
> };
> - const struct dma_fence_ops __rcu *ops;
> + const struct dma_fence_ops *ops;
[Severity: Low]
Should the remaining rcu_access_pointer(fence->ops) callers in the tree
also be updated now that the __rcu annotation is removed from
struct dma_fence::ops?
While dma_fence_is_array() and dma_fence_is_chain() are updated below,
several other functions converted in commits f4cc3ab824d6, 764f241ad227,
and 7519ba791b00 still wrap fence->ops in rcu_access_pointer(), which
causes Sparse to emit address-space mismatch warnings when building with
C=1:
drivers/gpu/drm/drm_crtc.c:fence_to_crtc():
BUG_ON(rcu_access_pointer(fence->ops) != &drm_crtc_fence_ops);
drivers/gpu/drm/scheduler/sched_fence.c:to_drm_sched_fence():
if (rcu_access_pointer(f->ops) == &drm_sched_fence_ops_scheduled)
return container_of(f, struct drm_sched_fence, scheduled);
if (rcu_access_pointer(f->ops) == &drm_sched_fence_ops_finished)
return container_of(f, struct drm_sched_fence, finished);
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c:to_amdgpu_amdkfd_fence():
if (rcu_access_pointer(f->ops) == &amdkfd_fence_ops)
return fence;
drivers/gpu/host1x/fence.c:host1x_fence_extract():
if (rcu_access_pointer(fence->ops) != &host1x_syncpt_fence_ops)
return -EINVAL;
> /*
> * We clear the callback list on kref_put so that by the time we
> * release the fence it is unused. No one should be adding to the
[ ... ]
> @@ -769,7 +761,7 @@ extern const struct dma_fence_ops dma_fence_chain_ops;
> */
> static inline bool dma_fence_is_array(struct dma_fence *fence)
> {
> - return rcu_access_pointer(fence->ops) == &dma_fence_array_ops;
> + return fence->ops == &dma_fence_array_ops;
> }
>
> /**
> @@ -780,7 +772,7 @@ static inline bool dma_fence_is_array(struct dma_fence *fence)
> */
> static inline bool dma_fence_is_chain(struct dma_fence *fence)
> {
> - return rcu_access_pointer(fence->ops) == &dma_fence_chain_ops;
> + return fence->ops == &dma_fence_chain_ops;
> }
>
> /**
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261020100034.759183-2-phasta@kernel.org?part=1
next prev parent reply other threads:[~2026-10-20 10:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 10:00 [RFC PATCH v2 0/3] Solve dma_fence's problems by locking Philipp Stanner
2026-10-20 10:00 ` [RFC PATCH v2 1/3] dma-fence: Remove RCU protection for fence->ops Philipp Stanner
2026-10-20 10:20 ` sashiko-bot [this message]
2026-10-20 10:00 ` [RFC PATCH v2 2/3] dma-fence: use lock to protect against module-unload Philipp Stanner
2026-10-20 10:19 ` sashiko-bot
2026-10-20 10:00 ` [RFC PATCH v2 3/3] dma-fence: Support unload for ops->get_XXX_name() Philipp Stanner
2026-10-20 10:27 ` sashiko-bot
2026-10-20 12:02 ` [RFC PATCH v2 0/3] Solve dma_fence's problems by locking Christian König
2026-10-20 14:41 ` Philipp Stanner
2026-10-20 15:07 ` Christian König
2026-10-20 15:36 ` Philipp Stanner
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=sashiko-outbox-178825@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=media-ci@linuxtv.org \
--cc=ojeda@kernel.org \
--cc=phasta@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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