From: "Jonghyuk Kim(MalHyuk)" <malhyuk97@gmail.com>
To: phasta@kernel.org, christian.koenig@amd.com,
tursulin@ursulin.net, matthew.brost@intel.com, dakr@kernel.org
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
mdaenzer@redhat.com, alessio.belle@imgtec.com,
luigi.santivetti@imgtec.com,
"Jonghyuk Kim(MalHyuk)" <malhyuk97@gmail.com>
Subject: [PATCH v4 2/3] drm/sched: add the fence ops-detach cleanup to the TODO list
Date: Fri, 4 Sep 2026 17:06:17 +0900 [thread overview]
Message-ID: <20260904080618.2098450-3-malhyuk97@gmail.com> (raw)
In-Reply-To: <20260904080618.2098450-1-malhyuk97@gmail.com>
The previous patch caches the timeline name so that get_timeline_name() no
longer dereferences a scheduler that a userspace-held fence has outlived.
That is a targeted fix: the underlying reason the callback is reachable at
all is that both drm_sched fences implement .release, so dma_fence never
detaches their ops on signalling. get_driver_name() has the same exposure
for module unload.
Dropping the .release callbacks is the complete fix, but it requires
auditing every to_drm_sched_fence() caller (ops-detach makes it return NULL
for signalled fences), a different identity mechanism for
pvr_queue_fence_is_native(), and a rework of the shared allocation's
reference handling. Record that as a TODO entry so the cleanup is not lost.
Suggested-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Jonghyuk Kim(MalHyuk) <malhyuk97@gmail.com>
---
Documentation/gpu/todo.rst | 39 ++++++++++++++++++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 14cf37590fc7..284aeba3c752 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -990,6 +990,45 @@ Contact:
Level: Beginner
+Detach the scheduler fence ops on signalling
+--------------------------------------------
+
+The dma-fence contract forbids touching driver-provided data - everything
+reachable through &dma_fence.ops - once a fence is signalled. dma_fence enforces
+that by detaching a fence's ops on signalling, but only for fences that carry
+neither a .release nor a .wait callback (see
+dma_fence_signal_timestamp_locked()).
+
+Both drm_sched fences implement .release, so their ops stay attached forever.
+That leaves the callbacks reachable on a long-signalled fence that userspace
+still holds through a sync_file or drm_syncobj, even after the scheduler is
+gone: get_timeline_name() used to dereference the freed &drm_sched_fence.sched
+(fixed by caching the name), and get_driver_name() can still return a string
+literal belonging to a module that has since been unloaded.
+
+Dropping the .release callbacks so that the ops are detached on signalling is
+the complete fix, and it is what the dma-fence rules ask for. It is not
+straightforward:
+
+Tasks:
+
+- Audit every to_drm_sched_fence() caller. Detaching the ops makes the helper
+ return NULL for a signalled fence, and callers such as
+ amdgpu_cs_p2_dependencies() and amdgpu_ctx_fence_time() dereference the result
+ unconditionally.
+- drm/imagination uses the ops pointer as an identity test in
+ pvr_queue_fence_is_native(); that needs a different mechanism.
+- Rework the reference handling. The scheduled and the finished fence share one
+ allocation, and the finished fence's .release currently drops the scheduled
+ fence's reference, so the callbacks cannot simply be deleted.
+
+Contact:
+
+- Philipp Stanner <phasta@kernel.org>
+- Christian König <christian.koenig@amd.com>
+
+Level: Advanced
+
Outside DRM
===========
--
2.43.0
next prev parent reply other threads:[~2026-09-05 15:04 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 8:06 [PATCH v4 0/3] drm/sched: fix use-after-free of the fence timeline name Jonghyuk Kim(MalHyuk)
2026-09-04 8:06 ` [PATCH v4 1/3] drm/sched: cache the timeline name to fix a use-after-free Jonghyuk Kim(MalHyuk)
2026-09-04 8:18 ` sashiko-bot
2026-09-04 8:20 ` Christian König
2026-09-04 8:31 ` Philipp Stanner
2026-09-04 12:49 ` Christian König
2026-09-04 19:06 ` Philipp Stanner
2026-09-07 9:15 ` Tvrtko Ursulin
2026-09-07 9:42 ` Philipp Stanner
2026-09-07 9:49 ` Philipp Stanner
2026-09-07 10:28 ` Tvrtko Ursulin
2026-09-07 10:34 ` Tvrtko Ursulin
2026-09-07 10:47 ` Philipp Stanner
2026-09-07 11:06 ` Tvrtko Ursulin
2026-09-07 11:15 ` Philipp Stanner
2026-09-07 12:59 ` Christian König
2026-09-07 13:38 ` Philipp Stanner
2026-09-07 15:21 ` Christian König
2026-09-08 10:49 ` Jonghyuk Kim(MalHyuk)
2026-09-08 11:07 ` Philipp Stanner
2026-09-09 0:37 ` Jonghyuk Kim(MalHyuk)
2026-09-09 7:44 ` Philipp Stanner
2026-09-07 12:28 ` Tvrtko Ursulin
2026-09-08 15:20 ` Tvrtko Ursulin
2026-09-07 12:18 ` Alessio Belle
2026-09-07 11:42 ` Christian König
2026-09-07 11:54 ` Philipp Stanner
2026-09-04 8:31 ` Jonghyuk Kim(MalHyuk)
2026-09-04 8:39 ` Philipp Stanner
2026-09-04 9:11 ` Jonghyuk Kim(MalHyuk)
2026-09-04 9:07 ` Tvrtko Ursulin
2026-09-04 9:57 ` Danilo Krummrich
2026-09-04 10:51 ` Philipp Stanner
2026-09-04 8:06 ` Jonghyuk Kim(MalHyuk) [this message]
2026-09-04 8:06 ` [PATCH v4 3/3] drm/sched/tests: add a UAF regression test for the timeline name Jonghyuk Kim(MalHyuk)
2026-09-04 8:15 ` sashiko-bot
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=20260904080618.2098450-3-malhyuk97@gmail.com \
--to=malhyuk97@gmail.com \
--cc=alessio.belle@imgtec.com \
--cc=christian.koenig@amd.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luigi.santivetti@imgtec.com \
--cc=matthew.brost@intel.com \
--cc=mdaenzer@redhat.com \
--cc=phasta@kernel.org \
--cc=tursulin@ursulin.net \
/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.