On 5/6/25 10:22, Liang, Prike wrote:
>>> - /* attach gfx eviction fence */
>>> + /* attach gfx the validated eviction fence */
>>> r = amdgpu_eviction_fence_attach(&fpriv->evf_mgr, abo);
>>> if (r) {
>>> DRM_DEBUG_DRIVER("Failed to attach eviction fence to BO\n");
>>> + amdgpu_bo_unreserve(abo);
>> Adding this here looks like the only valid fix in the patch.
> As the eviction fence will be invalidated until the user queue is created
> from the user space, here it requires validating the eviction fence before
> trying to attach and detach it to the reservation.
> I will try to draft a patch for validating the eviction fence at
> attach/detach separately with this attach error handler change.
No, that is clearly incorrect.
See the eviction fence works like this:
Validating thread
* Create new eviction fence
* Publish eviction fence
* Lock all BOs
* Replace eviction fence
Attaching:
* Lock BO
* Attach current eviction fence
* Unlock BO
Detaching:
* Lock BO
* Unconditionally detach all possible eviction fences, no matter if new or old.
* Unlock BO
This order is necessary or otherwise you break the logic here.
Any additional check will completely mess that up because it makes the
operation racy.
Regards,
Christian.
>
> Thanks,
> Prike
>
>>
>> Regards,
>> Christian.
>>
>>> return r;
>>> }
>>>
