On 10/13/26 16:13, Benjamin Cheng wrote:
> 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.
Vitaly and I already found the real root cause for this and I'm about to push
the fix to amd-staging-drm-next.
Regards,
Christian.
>
> 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);
> }
