AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Liang, Prike" <Prike.Liang@amd.com>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"Lazar, Lijo" <Lijo.Lazar@amd.com>,
	"Prosyak, Vitaly" <Vitaly.Prosyak@amd.com>
Subject: Re: [PATCH 1/9] drm/amdgpu: defer GPU recovery after userq eviction failure
Date: Wed, 14 Oct 2026 12:56:54 +0200	[thread overview]
Message-ID: <c4b15d6f-cdcd-4f85-ad0b-cb7365f5567e@amd.com> (raw)
In-Reply-To: <PH7PR12MB60001D76F73B9883506282A8FB9D2@PH7PR12MB6000.namprd12.prod.outlook.com>

On 10/14/26 11:02, Liang, Prike wrote:
> AMD General
> 
> Regards,
>       Prike
> 
>> -----Original Message-----
>> From: Koenig, Christian <Christian.Koenig@amd.com>
>> Sent: Tuesday, October 13, 2026 5:26 PM
>> To: Liang, Prike <Prike.Liang@amd.com>; amd-gfx@lists.freedesktop.org
>> Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Lazar, Lijo
>> <Lijo.Lazar@amd.com>; Prosyak, Vitaly <Vitaly.Prosyak@amd.com>
>> Subject: Re: [PATCH 1/9] drm/amdgpu: defer GPU recovery after userq eviction
>> failure
>>
>> On 10/13/26 10:24, Prike Liang wrote:
>>> On userq eviction failure, the suspend worker waits for reset_work
>>> while holding userq_mutex and inside a DMA-fence signaling section.
>>> This makes eviction-fence completion depend on GPU recovery finishing,
>>> although recovery can itself require memory allocation and eviction.
>>
>> Absolutely clear NAK to that!
>>
>> GPU recovery is to unlock memory allocation and eviction, so it can *NEVER*
>> allocate memory nor depend on eviction to complete.
>>
>> This patch here is just utterly nonsense. What we need to avoid is to touch the userq
>> mutex and/or any eviction fence from the GPU recovery.
> 
> You're right, the current lock ordering userq mutex-> reset semaphore in the userq eviction signaling path does not need to change,
> as it matches the order declared in amdgpu_lockdep_init(). On further check, the VCN/UVD IB test may perform a memory
> allocation with GFP_KERNEL that triggers reclaim during GPU recovery. We may need a follow-up patch to address the resulting potential deadlock.

Yeah that is a really good catch. That needs to use GFP_ATOMIC so that we can use the emergency reserves.

That should probably be ok since the memory is immediately freed up again.

Regards,
Christian.

> 
> Regards,
> Prike
> 
> Regards,
>> Christian.
>>
>>>
>>> Fixes: c8ed2de0f2ee ("drm/amdgpu: rework userq reset work handling")
>>> Signed-off-by: Prike Liang <Prike.Liang@amd.com>
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c | 12 +++++++++---
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c          | 10 +++-------
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h          |  2 +-
>>>  3 files changed, 13 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c
>>> index 082d045edf45..c2d1bc7decba 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_eviction_fence.c
>>> @@ -65,6 +65,7 @@ amdgpu_eviction_fence_suspend_worker(struct work_struct
>> *work)
>>>     struct amdgpu_userq_mgr *uq_mgr = &fpriv->userq_mgr;
>>>     struct dma_fence *ev_fence;
>>>     bool cookie;
>>> +   int r;
>>>
>>>     mutex_lock(&uq_mgr->userq_mutex);
>>>
>>> @@ -79,21 +80,26 @@ amdgpu_eviction_fence_suspend_worker(struct
>> work_struct *work)
>>>     cookie = dma_fence_begin_signalling();
>>>
>>>     ev_fence = amdgpu_evf_mgr_get_fence(evf_mgr);
>>> -   amdgpu_userq_evict(uq_mgr);
>>> +   r = amdgpu_userq_evict(uq_mgr);
>>>
>>>     /*
>>>      * Signaling the eviction fence must be done while holding the
>>>      * userq_mutex. Otherwise we won't resume the queues before issuing the
>>>      * next fence.
>>>      */
>>> -   dma_fence_signal(ev_fence);
>>> +   if (!r)
>>> +           dma_fence_signal(ev_fence);
>>>     dma_fence_end_signalling(cookie);
>>>     dma_fence_put(ev_fence);
>>>
>>> -   if (!evf_mgr->shutdown)
>>> +   if (!r && !evf_mgr->shutdown)
>>>             schedule_delayed_work(&uq_mgr->resume_work, 0);
>>>
>>>     mutex_unlock(&uq_mgr->userq_mutex);
>>> +
>>> +   if (r)
>>> +           amdgpu_reset_domain_schedule(uq_mgr->adev->reset_domain,
>>> +                                        &uq_mgr->reset_work);
>>>  }
>>>
>>>  int amdgpu_evf_mgr_attach_fence(struct amdgpu_eviction_fence_mgr
>>> *evf_mgr, diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
>>> index 3fe91fdafe55..5fef0cc7703c 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
>>> @@ -1308,13 +1308,9 @@ amdgpu_userq_evict_all(struct amdgpu_userq_mgr
>> *uq_mgr)
>>>                     ret = r;
>>>     }
>>>
>>> -   if (ret) {
>>> +   if (ret)
>>>             drm_file_err(uq_mgr->file,
>>>                          "Couldn't unmap all the queues, eviction failed ret=%d\n",
>> ret);
>>> -           amdgpu_reset_domain_schedule(uq_mgr->adev->reset_domain,
>>> -                                        &uq_mgr->reset_work);
>>> -           flush_work(&uq_mgr->reset_work);
>>> -   }
>>>     return ret;
>>>  }
>>>
>>> @@ -1334,10 +1330,10 @@ amdgpu_userq_wait_for_signal(struct
>> amdgpu_userq_mgr *uq_mgr)
>>>     }
>>>  }
>>>
>>> -void
>>> +int
>>>  amdgpu_userq_evict(struct amdgpu_userq_mgr *uq_mgr)  {
>>> -   amdgpu_userq_evict_all(uq_mgr);
>>> +   return amdgpu_userq_evict_all(uq_mgr);
>>>  }
>>>
>>>  int amdgpu_userq_mgr_init(struct amdgpu_userq_mgr *userq_mgr, struct
>>> drm_file *file_priv, diff --git
>>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h
>>> index 488dc21d7c81..4dcf6151de6a 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.h
>>> @@ -163,7 +163,7 @@ void amdgpu_userq_mgr_cancel_resume(struct
>>> amdgpu_userq_mgr *userq_mgr);  void amdgpu_userq_mgr_fini(struct
>>> amdgpu_userq_mgr *userq_mgr);
>>>
>>>  void amdgpu_userq_wait_for_signal(struct amdgpu_userq_mgr *uq_mgr);
>>> -void amdgpu_userq_evict(struct amdgpu_userq_mgr *uq_mgr);
>>> +int amdgpu_userq_evict(struct amdgpu_userq_mgr *uq_mgr);
>>>
>>>  void amdgpu_userq_ensure_ev_fence(struct amdgpu_userq_mgr *userq_mgr,
>>>                               struct amdgpu_eviction_fence_mgr *evf_mgr);
> 


      reply	other threads:[~2026-10-14 10:57 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-13  8:24 [PATCH 1/9] drm/amdgpu: defer GPU recovery after userq eviction failure Prike Liang
2026-10-13  8:24 ` [PATCH 2/9] drm/amdgpu: skip VKMS mode-config helpers during GPU reset Prike Liang
2026-10-13  9:27   ` Christian König
2026-10-15  3:45     ` Liang, Prike
2026-10-15  8:32       ` Christian König
2026-10-13  8:24 ` [PATCH 3/9] drm/amdgpu: skip VMHUB fault handling while the device is inaccessible Prike Liang
2026-10-13  8:24 ` [PATCH 4/9] drm/amdgpu/userq: complete hung queue fences after successful removal Prike Liang
2026-10-13  8:24 ` [PATCH 5/9] drm/amdgpu: finish GPU recovery callbacks before restarting schedulers Prike Liang
2026-10-13  8:24 ` [PATCH 6/9] drm/amdgpu: serialize JPEG and VCN idle work with GPU reset Prike Liang
2026-10-13  9:28   ` Christian König
2026-10-13  8:24 ` [PATCH 7/9] drm/amdgpu/userq: take reset_domain->sem before userq_mutex in destroy Prike Liang
2026-10-13  9:30   ` Christian König
2026-10-15  6:38     ` Liang, Prike
2026-10-13  8:24 ` [PATCH 8/9] drm/amdgpu/userq: take reset_domain->sem before userq_mutex in create Prike Liang
2026-10-13  8:24 ` [PATCH 9/9] drm/amdgpu/mes: skip unmap queue notification during GPU reset Prike Liang
2026-10-13  9:26 ` [PATCH 1/9] drm/amdgpu: defer GPU recovery after userq eviction failure Christian König
2026-10-14  9:02   ` Liang, Prike
2026-10-14 10:56     ` Christian König [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c4b15d6f-cdcd-4f85-ad0b-cb7365f5567e@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Lijo.Lazar@amd.com \
    --cc=Prike.Liang@amd.com \
    --cc=Vitaly.Prosyak@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox