On 5/8/26 04:24, Liang, Prike wrote: >> amdgpu_debugfs_userq_init(filp, queue, qid); >> + amdgpu_userq_put(queue); >> args->out.queue_id = qid; >> return 0; > > Should this userq creation get/put and error handler changes be splashed into > the patch#7?
Oh, good point! That looks like my branch somehow got messed up during rebase. This is reverting some of the changes from patch #7. Going to fix that, thanks. >> @@ -1091,7 +1100,7 @@ amdgpu_userq_vm_validate(struct amdgpu_userq_mgr >> *uq_mgr) >> if (unlikely(ret)) >> goto unlock_all; >> >> - ret = amdgpu_vm_lock_done_list(vm, &exec, 1); >> + ret = amdgpu_vm_lock_individual(vm, &exec, 1); > > > In the following ttm_bo_validate() may consumer all the reservation fence > slots by the reservation internal pipeline eviction fences or move fences, > then this will > result in the userq eviction fences attached failed due to the out of > reservation fence slots. How about set the amdgpu_vm_lock_individual() > reservation fence > number as TTM_NUM_MOVE_FENCES + 1 (validate() move path fence slots + userq > eviction fence)? Good point as well. This code was written before Pierre-Erics patch to introduce TTM_NUM_MOVE_FENCES was merged and I've forgotten to adjust it. Thanks for the comments, Christian.
