[AMD Official Use Only - AMD Internal Distribution Only]
From: Chen, Xiaogang <xiaogang.c...@amd.com> Sent: Monday, February 10, 2025 10:18 AM To: Deng, Emily <emily.d...@amd.com>; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdkfd: Fix the deadlock in svm_range_restore_work On 2/7/2025 9:02 PM, Deng, Emily wrote: [AMD Official Use Only - AMD Internal Distribution Only] [AMD Official Use Only - AMD Internal Distribution Only] Ping....... Emily Deng Best Wishes -----Original Message----- From: Emily Deng <emily.d...@amd.com><mailto:emily.d...@amd.com> Sent: Friday, February 7, 2025 6:28 PM To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> Cc: Deng, Emily <emily.d...@amd.com><mailto:emily.d...@amd.com> Subject: [PATCH] drm/amdkfd: Fix the deadlock in svm_range_restore_work It will hit deadlock in svm_range_restore_work ramdonly. Detail as below: 1.svm_range_restore_work ->svm_range_list_lock_and_flush_work ->mmap_write_lock 2.svm_range_restore_work ->svm_range_validate_and_map ->amdgpu_vm_update_range ->amdgpu_vm_ptes_update ->amdgpu_vm_pt_alloc ->svm_range_evict_svm_bo_worker svm_range_evict_svm_bo_worker is a function running by a kernel task from default system_wq. It is not the task that runs svm_range_restore_work which is from system_freezable_wq. The second task may need wait the first task to release mmap_write_lock, but there is no cycle lock dependency. Can you explain more how deadlock happened? If a deadlock exists between two tasks there are should be at least two locks used by both tasks. Regards Xiaogang In Step 2, during the amdgpu_vm_pt_alloc process, the system encounters insufficient memory and triggers an eviction. This initiates the svm_range_evict_svm_bo_worker task, and waits for the eviction_fence to be signaled. However, the svm_range_evict_svm_bo_worker cannot acquire the mmap_read_lock(mm), preventing it from signaling the eviction_fence. As a result, amdgpu_vm_pt_alloc remains incomplete and cannot release the mmap_write_lock(mm). Which means the svm_range_restore_work task holds the mmap_write_lock(mm) and is stuck waiting for the eviction_fence to be signaled by svm_range_evict_svm_bo_worker. However, svm_range_evict_svm_bo_worker is itself blocked, unable to acquire the mmap_read_lock(mm). This creates a deadlock. Emily Deng Best Wishes ->mmap_read_lock(deadlock here, because already get mmap_write_lock) How to fix? Downgrade the write lock to read lock. Signed-off-by: Emily Deng <emily.d...@amd.com><mailto:emily.d...@amd.com> --- drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c index bd3e20d981e0..c907e2de3dde 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c @@ -1841,6 +1841,7 @@ static void svm_range_restore_work(struct work_struct *work) mutex_lock(&process_info->lock); svm_range_list_lock_and_flush_work(svms, mm); mutex_lock(&svms->lock); + mmap_write_downgrade(mm); evicted_ranges = atomic_read(&svms->evicted_ranges); @@ -1890,7 +1891,7 @@ static void svm_range_restore_work(struct work_struct *work) out_reschedule: mutex_unlock(&svms->lock); - mmap_write_unlock(mm); + mmap_read_unlock(mm); mutex_unlock(&process_info->lock); /* If validation failed, reschedule another attempt */ -- 2.34.1
