drm/amdgpu: reserve eviction-fence slot at WPTR caller

Root cause analysis showed that the previous workaround was fixing the
symptom in the wrong layer.

Problem:
  kernel BUG at drivers/dma-buf/dma-resv.c:319!
  BUG_ON(fobj->num_fences >= fobj->max_fences)
  Workqueue: events amdgpu_userq_restore_worker

- amdgpu_evf_mgr_attach_fence() had been temporarily taught to reserve/add
  fence bookkeeping internally as a workaround.
- This hid the real contract violation and made reservation policy implicit
  inside a helper.

Review clarification:
- The helper-side dma_resv_add_fence-related workaround was only an intended
  proposal sent for review discussion, not the final direction.
- Final fix keeps fence-slot reservation explicit in callers and leaves the
  helper free of policy decisions.

Findings from investigation:
- drm_exec_prepare_obj() both locks and reserves fence slots.
- drm_exec_lock_obj() only locks and does not reserve slots.
- Existing attach_fence callers in the GEM/userq restore flows already reserve
  TTM_NUM_MOVE_FENCES + 1 before adding the bookkeeping eviction fence.
- The WPTR mapping path in mes_userq_create_wptr_mapping() used
  drm_exec_lock_obj() and then called amdgpu_evf_mgr_attach_fence(), so this
  specific path could add a fence without pre-reserved space.

Fix:
- Switch the WPTR mapping path to drm_exec_prepare_obj(...,
  TTM_NUM_MOVE_FENCES + 1), restoring the caller-side reservation contract.
- Remove the helper-side reservation workaround from
  amdgpu_evf_mgr_attach_fence().

Why this is the right layer:
- Reservation policy stays explicit at call sites that define how many fences
  may be added in that execution context.
- The helper only performs validate + add_fence when called with a properly
  prepared reservation object, matching the existing drm_exec model.

Fixes: 7264bc10c7c6 (drm/amdgpu: dont pin wptr bo instead use eviction fence)
Cc: Sunil Khatri <sunil.khatri@amd.com>
Cc: Prike Liang <prike.liang@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Reviewed-by: Prike Liang <prike.liang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

0 files changed, 0 insertions, 0 deletions