On 2026-06-16 05:09, Christian König wrote:
>
> On 6/12/26 07:52, Srinivasan Shanmugam wrote:
>> Signal GPU_RESET EVENTFD subscriptions from the GPU recovery path.
>>
>> The GPU recovery flow already determines when a device reset has
>> completed successfully. Use that point to wake up matching EVENTFD
>> subscribers.
>>
>> GPU_RESET is a device-scoped event, so no queue object is used. All
>> processes that subscribed to GPU_RESET on the device are notified.
>>
>> EVENTFD remains notification-only.
>>
>> Cc: Alex Deucher <[email protected]>
>> Cc: Christian König <[email protected]>
>> Signed-off-by: Srinivasan Shanmugam <[email protected]>
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 30 +++++++++++++++++++++-
>> 1 file changed, 29 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index e46cdd6ecd42..8f28716912c7 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -5694,6 +5694,32 @@ static int amdgpu_device_asic_reset(struct
>> amdgpu_device *adev,
>> return r;
>> }
>>
>> +/*
>> + * Signal GPU_RESET EVENTFD subscriptions for all open DRM files.
>> + *
>> + * GPU reset is a device-wide event rather than being associated with a
>> + * specific user queue. Notify every process that subscribed to the
>> + * GPU_RESET event on this device.
>> + */
>> +static void amdgpu_device_eventfd_signal_gpu_reset(struct amdgpu_device
>> *adev)
>> +{
>> + struct drm_device *ddev = adev_to_drm(adev);
>> + struct drm_file *file;
>> +
>> + mutex_lock(&ddev->filelist_mutex);
> Please double check what other locks can be held under the
> ddev->filelist_mutex.
>
> @Vitaly do we have ddev->filelist_mutex in our lockdep handling already? I
> don't think so, if no could we add it?
Hi Christian,
No, ddev->filelist_mutex was not in our lockdep annotations. The previous
hierarchy covered 9 lock levels (userq_sch_mutex through mmio_idx_lock) but
filelist_mutex was not among them.
I checked the existing filelist_mutex usage in amdgpu:
- amdgpu_gem_force_release(): takes filelist_mutex -> file->table_lock
- debugfs gem_info: takes filelist_mutex, reads BO info
- debugfs vm_info: takes filelist_mutex -> amdgpu_bo_reserve() (dma_resv)
None of these hold reset_domain->sem, so the ordering in Srini's patch
(reset_domain->sem -> filelist_mutex) does not conflict with existing code.
I have added filelist_mutex to the lockdep annotations as level 7 (inner to
reset_lock, outer to srbm_mutex). The updated hierarchy is now 10 levels:
1. userq_sch_mutex - Global userq scheduler
2. userq_mutex - Per-context userq
3. notifier_lock - MMU notifier
4. vram_lock - VRAM allocator
5. reset_domain->sem - GPU reset synchronization
6. reset_lock - Reset control
7. filelist_mutex - DRM file list iteration (NEW)
8. srbm_mutex - SRBM register access
9. grbm_idx_mutex - GRBM index access
10. mmio_idx_lock - MMIO index (spinlock, innermost)
The patch compiles cleanly and is on branch lockdep_task (commit 627073ba8951).
Thanks,
Vitaly
> Thanks in advance,
> Christian.
>
>> +
>> + list_for_each_entry(file, &ddev->filelist, lhead) {
>> + struct amdgpu_fpriv *fpriv = file->driver_priv;
>> +
>> + if (fpriv)
>> + amdgpu_eventfd_signal(&fpriv->eventfd_mgr,
>> + DRM_AMDGPU_EVENT_TYPE_GPU_RESET,
>> + NULL);
>> + }
>> +
>> + mutex_unlock(&ddev->filelist_mutex);
>> +}
>> +
>> static int amdgpu_device_sched_resume(struct list_head *device_list,
>> struct amdgpu_reset_context *reset_context,
>> bool job_signaled)
>> @@ -5738,6 +5764,9 @@ static int amdgpu_device_sched_resume(struct list_head
>> *device_list,
>> } else {
>> dev_info(tmp_adev->dev, "GPU reset(%d) succeeded!\n",
>> atomic_read(&tmp_adev->gpu_reset_counter));
>> +
>> + amdgpu_device_eventfd_signal_gpu_reset(tmp_adev);
>> +
>> if (amdgpu_acpi_smart_shift_update(tmp_adev,
>> AMDGPU_SS_DEV_D0))
>> dev_warn(tmp_adev->dev,
>> @@ -5775,7 +5804,6 @@ static void amdgpu_device_gpu_resume(struct
>> amdgpu_device *adev,
>> }
>> }
>>
>> -
>> /**
>> * amdgpu_device_gpu_recover - reset the asic and recover scheduler
>> *
