From: Vitaly Prosyak <[email protected]>
During user queue restore, the eviction-fence rearm path can attach a
replacement BOOKKEEP fence after the BO reservation has been unlocked.
Because dma_resv_unlock() discards unused pre-reserved capacity, a BO
with no remaining fences can reach dma_resv_add_fence() with max_fences
equal to zero. This triggers the dma-resv BUG_ON at dma-resv.c:319 and
can crash amdgpu_userq_restore_worker.
The first two patches revert earlier caller-side reservations. The root
PD reservation and the WPTR-caller reservation are no longer required
once the slot is reserved at the operation that actually attaches the
replacement eviction fence. Removing them avoids retaining redundant
fence capacity and keeps the reservation accounting local to the rearm
path.
The third patch reserves one fence slot in amdgpu_evf_mgr_rearm(),
immediately before amdgpu_evf_mgr_attach_fence() is called for each
locked BO. The BO is already held by the drm_exec context, so the
reservation remains valid for dma_resv_add_fence(). The reservation is
kept explicit in the rearm path rather than hidden in the attach helper.
The fix was validated with repeated amd_deadlock runs, including the
userqueue restore reproducer.
Vitaly Prosyak (3):
Revert "drm/amdgpu: reserve root PD fence slots for userq
eviction-fence rearm"
Revert "drm/amdgpu: reserve eviction-fence slot at WPTR caller"
drm/amdgpu: Reserve eviction fence slot during userq rearm
drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c | 8 ++++++++
drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 6 +-----
drivers/gpu/drm/amd/amdgpu/mes_userqueue.c | 3 +--
3 files changed, 10 insertions(+), 7 deletions(-)
--
2.55.0
