[PATCH] drm/amdgpu: return reserve errors from amdgpu_gfx_kiq_init()

Runyu Xiao posted 1 patch 1 month ago
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
[PATCH] drm/amdgpu: return reserve errors from amdgpu_gfx_kiq_init()
Posted by Runyu Xiao 1 month ago
amdgpu_gfx_kiq_init() reserves kiq->eop_obj after mapping the buffer.
If amdgpu_bo_reserve() fails, the code still unmaps and unreserves the
BO and then returns success.

Return the reserve error, but keep the kunmap cleanup. Only call
amdgpu_bo_unreserve() on the successful-reservation path.

Fixes: 71c37505e7ea ("drm/amdgpu/gfx: move more common KIQ code to amdgpu_gfx.c")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index c5aa465231c4..630d0fd9ac13 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -241,8 +241,11 @@ int amdgpu_gfx_kiq_init(struct amdgpu_device *adev,
 	memset(hpd, 0, hpd_size);
 
 	r = amdgpu_bo_reserve(kiq->eop_obj, true);
-	if (unlikely(r != 0))
+	if (unlikely(r != 0)) {
 		dev_warn(adev->dev, "(%d) reserve kiq eop bo failed\n", r);
+		amdgpu_bo_kunmap(kiq->eop_obj);
+		return r;
+	}
 	amdgpu_bo_kunmap(kiq->eop_obj);
 	amdgpu_bo_unreserve(kiq->eop_obj);
 
-- 
2.34.1
Re: [PATCH] drm/amdgpu: return reserve errors from amdgpu_gfx_kiq_init()
Posted by Runyu Xiao 1 month ago
Thanks for the review.

Before preparing a resend, I rechecked the reservation path:

  amdgpu_bo_reserve(bo, true)
    -> ttm_bo_reserve(bo, false, false, NULL)
    -> dma_resv_lock(...)

This is an uninterruptible, blocking lock acquisition without a ww acquire
context. Under the current locking semantics, contention is waited out and
the call cannot normally return -EINTR, -EBUSY, -EDEADLK, or -EALREADY.

The reserve-failure path targeted by this patch is therefore not reachable
under the current locking semantics, and this patch does not address a
currently triggerable bug.

I am withdrawing the patch and will not send a v2. Thanks for catching this.

Runyu Xiao