AMD General
Regards,
Prike
> -----Original Message-----
> From: amd-gfx <[email protected]> On Behalf Of
> [email protected]
> Sent: Thursday, September 10, 2026 8:46 AM
> To: [email protected]
> Cc: Prosyak, Vitaly <[email protected]>; Liang, Prike
> <[email protected]>; Khatri, Sunil <[email protected]>; Koenig, Christian
> <[email protected]>; Deucher, Alexander
> <[email protected]>
> Subject: [PATCH 2/2] drm/amdgpu: reserve root PD fence slots for userq
> eviction-
> fence rearm
>
> From: Vitaly Prosyak <[email protected]>
>
> Root cause:
> - In userq restore/rearm, root PD was locked with amdgpu_vm_lock_pd(vm, &exec,
> 1).
> - Later in the same drm_exec context, amdgpu_evf_mgr_rearm() attaches
> BOOKKEEP eviction fences to all locked BOs.
> - In this flow, root PD validation/update can also consume move-fence slots,
> so reserving only +1 at PD lock time is not sufficient under stress.
>
> Fix:
> - Reserve caller-side slots at the actual source by switching to:
> amdgpu_vm_lock_pd(vm, &exec, TTM_NUM_MOVE_FENCES + 1)
>
> This keeps reservation policy in callers, consistent with Christian Konig
> feedback
> and with amdgpu_gem_object_open() where callers reserve
> TTM_NUM_MOVE_FENCES + 1 before attaching eviction fences.
>
> Credit:
> - Christian Konig: confirmed fence-slot reservation belongs to callers and
> asked to investigate why +1 was still not enough.
> - Prike Liang: clarified the initial variant was workaround-only and
> developed that initial version independently.
>
> Cc: Prike Liang <[email protected]>
> Cc: Sunil Khatri <[email protected]>
> Cc: Christian König <[email protected]>
> Cc: Alex Deucher <[email protected]>
> Signed-off-by: Vitaly Prosyak <[email protected]>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> index 3938f7b8ec4b..12fbff02e4b5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> @@ -1043,7 +1043,11 @@ amdgpu_userq_vm_validate_and_restore_queue(struct
> amdgpu_userq_mgr *uq_mgr)
> retry_lock:
> drm_exec_init(&exec, DRM_EXEC_IGNORE_DUPLICATES, 0);
> drm_exec_until_all_locked(&exec) {
> - ret = amdgpu_vm_lock_pd(vm, &exec, 1);
> + /*
> + * Rearm adds one BOOKKEEP fence and validation may queue
> move fences
> + * on the root PD BO, so reserve caller-side slots accordingly.
> + */
> + ret = amdgpu_vm_lock_pd(vm, &exec, TTM_NUM_MOVE_FENCES
> + 1);
IIRC, the PD reservation fence slots had been corrected a while ago on the
drm-next, could you please further check on the latest drm-next branch?
> drm_exec_retry_on_contention(&exec);
> if (unlikely(ret))
> goto unlock_all;
> --
> 2.54.0
