If the eviction fence restore gets triggered while a BO unmap is
happening, the attempt to lock the BO for restore will fail. On retry,
drm_exec locks the contended BO first, but it is not actually required
to be locked, and the eviction fence should not be attached to such a
BO.
If the BO was freed, this extra lock will cause BUG_ON to fire in
dma_resv_add_fence, since the gem object and its resv lists are freed
already.
drm_exec::prelocked remains set only if the object was locked on retry
but not actually requested to be locked, so use that to detect this
case and skip it.
Fixes: 2cd7284ba54b ("drm/amdgpu: completely rework eviction fence handling v2")
Signed-off-by: Benjamin Cheng <[email protected]>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c
index a0802012de49..1e119173564b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c
@@ -145,6 +145,10 @@ int amdgpu_evf_mgr_rearm(struct amdgpu_eviction_fence_mgr
*evf_mgr,
/* And add it to all existing BOs */
drm_exec_for_each_locked_object(exec, index, obj) {
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+ /* A BO may be locked after it has been dropped from the VM due
+ * to how drm_exec treats contention. */
+ if (obj == exec->prelocked)
+ continue;
amdgpu_evf_mgr_attach_fence(evf_mgr, bo);
}
--
2.55.0
