From: Philipp Stanner <phasta@kernel.org>
To: "Felix Kuehling" <Felix.Kuehling@amd.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Sumit Semwal" <sumit.semwal@linaro.org>
Cc: amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
Philipp Stanner <phasta@kernel.org>
Subject: [PATCH] drm/amdgpu: Harden against potential deadlock
Date: Mon, 26 Oct 2026 15:15:42 +0100 [thread overview]
Message-ID: <20261026141541.469727-2-phasta@kernel.org> (raw)
amdgpu's KFD eviction fence's dma_fence ops->enable_signaling() contains
a dma_fence_is_signaled() check.
ops->enable_signaling() is currently consistently being called with the
dma_fence lock held. dma_fence_is_signaled() might try to take this lock
in its dma_fence_signal() call.
This deadlock can currently not occur because the amdkfd_fence_ops do
not implement ops->signaled. Should that ever be added, however,
deadlocks might occur occasionally once the fastpath check in
dma_fence_is_signaled() is skipped.
Replace dma_fence_is_signaled() with dma_fence_is_signaled_locked().
Signed-off-by: Philipp Stanner <phasta@kernel.org>
---
As detailed in my recent discussions with Christian [1], I also think
that drivers should be very tightly constrained as to what they do in
the fence_ops. I think at the very least they shouldn't use any
dma_fence functions there.
So we could also remove this check here completely;
__dma_fence_enable_signaling() already checks the signaled-flag, after
all, but I'm not sure whether that might break amdgpu.
P.
[1] https://lore.kernel.org/dri-devel/320b6e7c75da6f05c015e89df0e2c7d11f20d70a.camel@mailbox.org/
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
index 9b10d015671c..61621eebb2b0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
@@ -123,7 +123,8 @@ static bool amdkfd_fence_enable_signaling(struct dma_fence *f)
if (!fence)
return false;
- if (dma_fence_is_signaled(f))
+ /* The enable_signaling() ops is called under lock protection. */
+ if (dma_fence_is_signaled_locked(f))
return true;
if (!kgd2kfd_schedule_evict_and_restore_process(fence->mm, fence->context_id, f))
--
2.56.0
next reply other threads:[~2026-10-26 14:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 14:15 Philipp Stanner [this message]
2026-10-26 18:31 ` Felix Kuehling
2026-10-27 11:51 ` Christian König
2026-10-27 13:18 ` 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=20261026141541.469727-2-phasta@kernel.org \
--to=phasta@kernel.org \
--cc=Felix.Kuehling@amd.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=simona@ffwll.ch \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®