On 3/17/26 12:21, Liang, Prike wrote: > [Public] > > Regards, > Prike > >> -----Original Message----- >> From: Koenig, Christian <[email protected]> >> Sent: Tuesday, March 17, 2026 5:57 PM >> To: Liang, Prike <[email protected]>; [email protected]; Deucher, >> Alexander >> <[email protected]>; Mohan Marimuthu, Yogesh >> <[email protected]>; SHANMUGAM, SRINIVASAN >> <[email protected]>; Khatri, Sunil <[email protected]>; >> [email protected] >> Subject: Re: [PATCH 04/11] drm/amdgpu: completely rework eviction fence >> handling >> >> On 3/13/26 09:28, Liang, Prike wrote: >>>> +void amdgpu_evf_mgr_attach_fence(struct amdgpu_eviction_fence_mgr >> *evf_mgr, >>>> + struct amdgpu_bo *bo) { >>>> + struct dma_fence *ev_fence = amdgpu_evf_mgr_get_fence(evf_mgr); >>>> + struct dma_resv *resv = bo->tbo.base.resv; >>> >>> Before adding the attached fence, there requires allocating the reservation >>> fence >> slot first. >> >> No, the caller does that using the drm_exec. >> >> Additional to that it is way to late to do any memory allocation here since >> that could >> cycle back and wait for us to attach the eviction fence. >> >> So by reserving a slot here you would just create a potential deadlock. > > Is possible pass the wrong fence number through the > amdgpu_vm_lock_pd()/drm_exec_prepare_obj()? I saw the fence number assert > error during attaching the reservation fence.
Yeah that is perfectly possible. For kernel queues you need to have something like number_of_gang_members + 1 (for TTM) + 1 (for page table updates). For user queues we probably need 1 (for TTM) + 1 (for page tables updates) + 1 (for the eviction fence). Not sure if the calculation was really correct. Regards, Christian. > >> Regards, >> Christian.
