From: <gregkh@linuxfoundation.org>
To: 1468888505@139.com,Xinhui.Pan@amd.com,airlied@gmail.com,alexander.deucher@amd.com,amd-gfx@lists.freedesktop.org,christian.koenig@amd.com,daniel@ffwll.ch,dri-devel@lists.freedesktop.org,gregkh@linuxfoundation.org,patches@lists.linux.dev,rbmccav@gmail.com
Cc: <stable-commits@vger.kernel.org>
Subject: Patch "drm/radeon: delete radeon_fence_process in is_signaled, no deadlock" has been added to the 6.1-stable tree
Date: Tue, 03 Feb 2026 16:59:08 +0100 [thread overview]
Message-ID: <2026020308-sandpit-carbon-ce38@gregkh> (raw)
In-Reply-To: <20260202075855.947632-1-1468888505@139.com>
This is a note to let you know that I've just added the patch titled
drm/radeon: delete radeon_fence_process in is_signaled, no deadlock
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-radeon-delete-radeon_fence_process-in-is_signaled-no-deadlock.patch
and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From stable+bounces-213031-greg=kroah.com@vger.kernel.org Mon Feb 2 08:59:14 2026
From: Li hongliang <1468888505@139.com>
Date: Mon, 2 Feb 2026 15:58:55 +0800
Subject: drm/radeon: delete radeon_fence_process in is_signaled, no deadlock
To: gregkh@linuxfoundation.org, stable@vger.kernel.org, rbmccav@gmail.com
Cc: patches@lists.linux.dev, linux-kernel@vger.kernel.org, alexander.deucher@amd.com, christian.koenig@amd.com, Xinhui.Pan@amd.com, airlied@gmail.com, daniel@ffwll.ch, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Message-ID: <20260202075855.947632-1-1468888505@139.com>
From: Robert McClinton <rbmccav@gmail.com>
[ Upstream commit 9eb00b5f5697bd56baa3222c7a1426fa15bacfb5 ]
Delete the attempt to progress the queue when checking if fence is
signaled. This avoids deadlock.
dma-fence_ops::signaled can be called with the fence lock in unknown
state. For radeon, the fence lock is also the wait queue lock. This can
cause a self deadlock when signaled() tries to make forward progress on
the wait queue. But advancing the queue is unneeded because incorrectly
returning false from signaled() is perfectly acceptable.
Link: https://github.com/brave/brave-browser/issues/49182
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4641
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Robert McClinton <rbmccav@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)
Cc: stable@vger.kernel.org
[ Minor conflict resolved. ]
Signed-off-by: Li hongliang <1468888505@139.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_fence.c | 8 --------
1 file changed, 8 deletions(-)
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -362,14 +362,6 @@ static bool radeon_fence_is_signaled(str
return true;
}
- if (down_read_trylock(&rdev->exclusive_lock)) {
- radeon_fence_process(rdev, ring);
- up_read(&rdev->exclusive_lock);
-
- if (atomic64_read(&rdev->fence_drv[ring].last_seq) >= seq) {
- return true;
- }
- }
return false;
}
Patches currently in stable-queue which might be from 1468888505@139.com are
queue-6.1/vhost-scsi-fix-handling-of-multiple-calls-to-vhost_scsi_set_endpoint.patch
queue-6.1/fs-ntfs3-initialize-allocated-memory-before-use.patch
queue-6.1/drm-radeon-delete-radeon_fence_process-in-is_signaled-no-deadlock.patch
queue-6.1/ksmbd-fix-race-condition-in-rpc-handle-list-access.patch
queue-6.1/ksmbd-fix-use-after-free-in-ksmbd_session_rpc_open.patch
queue-6.1/drm-amdgpu-replace-mutex-with-spinlock-for-rlcg-register-access-to-avoid-priority-inversion-in-sriov.patch
queue-6.1/sctp-linearize-cloned-gso-packets-in-sctp_rcv.patch
prev parent reply other threads:[~2026-02-03 15:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 7:58 [PATCH 6.1.y] drm/radeon: delete radeon_fence_process in is_signaled, no deadlock Li hongliang
2026-02-03 15:59 ` gregkh [this message]
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=2026020308-sandpit-carbon-ce38@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=1468888505@139.com \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=patches@lists.linux.dev \
--cc=rbmccav@gmail.com \
--cc=stable-commits@vger.kernel.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