Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Missing reservation lock when calling amdgpu_bo_unpin() in amdgpu_userq_destroy_object() --
commit a94e7fa8193fda17368d3bdb773d56e5a1abc907 Author: Sunil Khatri <[email protected]> drm/amdgpu/userq: pin mqd and fw object bo to avoid eviction This commit pins the MQD and firmware object buffer objects to prevent them from being evicted while user queues are active. It adds amdgpu_bo_pin() during object creation and amdgpu_bo_unpin() during destruction. > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c > index 1add21160d218..e044feaaeb01d 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c [ ... ] > @@ -278,6 +284,7 @@ void amdgpu_userq_destroy_object(struct amdgpu_userq_mgr > *uq_mgr, > struct amdgpu_userq_obj *userq_obj) > { > amdgpu_bo_kunmap(userq_obj->obj); > + amdgpu_bo_unpin(userq_obj->obj); [Severity: High] Is it safe to call amdgpu_bo_unpin() here without holding the buffer object's reservation lock? In amdgpu_userq_create_object(), we hold the reservation lock (via amdgpu_bo_reserve) when calling amdgpu_bo_pin(), and when calling amdgpu_bo_unpin() in the error path. However, in amdgpu_userq_destroy_object(), the caller (like mes_userq_mqd_destroy()) does not appear to reserve the buffer object before calling this function. This means amdgpu_bo_unpin() might be executed without the required dma_resv lock, which is needed by the internal ttm_bo_unpin() call. > amdgpu_bo_unref(&userq_obj->obj); > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
