From: redducc <sushmit718@gmail.com>
To: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Tvrtko Ursulin" <tvrtko.ursulin@igalia.com>,
"Christian König" <christian.koenig@amd.com>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
"Philipp Stanner" <phasta@kernel.org>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: [PATCH] drm: Don't BUG when a CRTC fence signals during a name lookup
Date: Mon, 19 Oct 2026 16:17:31 +0000 [thread overview]
Message-ID: <20261019161731.2341-1-sushmit718@gmail.com> (raw)
dma_fence_signal_timestamp_locked() clears fence->ops on signalling when
the ops have neither a release nor a wait callback, which is the case
for drm_crtc_fence_ops.
dma_fence_driver_name() and dma_fence_timeline_name() load fence->ops,
check the signalled bit and then call into the ops. If the fence
signals between that check and the call, fence_to_crtc() rereads
fence->ops, finds NULL and hits the BUG_ON(). This takes down any
caller of SYNC_IOC_FILE_INFO on a CRTC out-fence, such as Android's
surfaceflinger, which hit it on a Snapdragon 8+ Gen 1 phone (msm).
The CRTC behind the fence outlives it, so reading the name after the
ops were cleared is fine. Only warn when the fence carries foreign ops.
Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3")
Assisted-by: LLM
Signed-off-by: redducc <sushmit718@gmail.com>
---
drivers/gpu/drm/drm_crtc.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 63ead8ba6756..1dbd0e9db536 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -158,7 +158,13 @@ static const struct dma_fence_ops drm_crtc_fence_ops;
static struct drm_crtc *fence_to_crtc(struct dma_fence *fence)
{
- BUG_ON(rcu_access_pointer(fence->ops) != &drm_crtc_fence_ops);
+ const struct dma_fence_ops *ops = rcu_access_pointer(fence->ops);
+
+ /*
+ * Signalling clears ops, and can race with a name lookup that already
+ * picked our callbacks, so only a foreign ops pointer is a bug.
+ */
+ WARN_ON_ONCE(ops && ops != &drm_crtc_fence_ops);
return container_of(fence->extern_lock, struct drm_crtc, fence_lock);
}
base-commit: 6a56f4f29711dd2da49f03a5b99ce53779e638d7
--
2.43.0
next reply other threads:[~2026-10-20 7:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 16:17 redducc [this message]
2026-10-20 6:53 ` [PATCH] drm: Don't BUG when a CRTC fence signals during a name lookup Philipp Stanner
2026-10-20 6:57 ` Tvrtko Ursulin
2026-10-20 7:04 ` Philipp Stanner
2026-10-20 11:05 ` 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=20261019161731.2341-1-sushmit718@gmail.com \
--to=sushmit718@gmail.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=phasta@kernel.org \
--cc=simona@ffwll.ch \
--cc=tvrtko.ursulin@igalia.com \
--cc=tzimmermann@suse.de \
/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.