On 12/10/2025 8:11 AM, Philip Yang wrote:
On 2025-12-09 17:13, Chen, Xiaogang wrote:
On 12/9/2025 2:36 PM, Philip Yang wrote:
Error handling path should unreserve bo then return failed.
Fixes: 305cd109b761 ("drm/amdkfd: Validate user queue update")
Signed-off-by: Philip Yang <[email protected]>
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
index 232103742712..6babdf025359 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
@@ -592,6 +592,7 @@ int pqm_update_queue_properties(struct
process_queue_manager *pqm,
p->queue_size)) {
pr_debug("ring buf 0x%llx size 0x%llx not mapped on
GPU\n",
p->queue_address, p->queue_size);
+ amdgpu_bo_unreserve(vm->root.bo);
but why need have amdgpu_bo_reserve before call kfd_queue_buffer_get?
kfd_queue_buffer_get just check if mapping at addr exist, it adds
bo_ref and mapping->bo_va->queue_refcount. Then after immediately
call kfd_queue_unref_bo_va and kfd_queue_buffer_put.
amdgpu_vm_bo_lookup_mapping access vm->va interval tree, this requires
to take vm lock.
ok, it locks a vm->root.bo. I sought it locks a general bo. I think the
lock/unlock can be inside kfd_queue_buffer_get before and after
amdgpu_vm_bo_lookup_mapping because that is what need be protected, then
do not have to care unlock after this function call as current case.
For such lock can we use drm_exec_init/amdgpu_vm_lock_pd instead, as it
is a more general way?
Regards
Xiaogang
Regards,
Philip
Regards
Xiaogang
return -EFAULT;
}
