On 2026-10-13 10:58, Christian König wrote:
> 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.
Ah, thanks I did not see that one. Indeed the same issue.
>
> 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);
>> }
