[PATCH] drm/amdgpu/userq: serialize queue map against GPU reset

[PATCH] drm/amdgpu/userq: serialize queue map against GPU reset

[Jesse Zhang]

Creating a user queue can race with a GPU reset. While recovery holds
reset_domain->sem for write, MES is unresponsive, so the ADD_QUEUE from
amdgpu_userq_map_helper() times out (-110) and an otherwise valid queue
create fails:

  amdgpu: MES(0) failed to respond to msg=ADD_QUEUE
  [drm:mes_userq_map [amdgpu]] *ERROR* Failed to map queue in HW, err (-110)
  amdgpu: [drm] *ERROR* ... Failed to map Queue
  amdgpu: [drm] *ERROR* ... Failed to create usermode queue

Take reset_domain->sem for read around the map so it runs only once MES
is back up. This mirrors amdgpu_userq_cleanup() and honors the
userq_mutex -> reset_domain->sem order; the reset path never takes
userq_mutex, so there is no deadlock.

Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
index 652599f08990..770635ab5298 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
@@ -745,7 +745,12 @@ amdgpu_userq_create(struct drm_file *filp, union drm_amdgpu_userq *args)
 	if (!adev->userq_halt_for_enforce_isolation ||
 	    ((queue->queue_type != AMDGPU_HW_IP_GFX) &&
 	     (queue->queue_type != AMDGPU_HW_IP_COMPUTE))) {
+		/* Serialize the map against an in-progress GPU reset (MES is
+		 * unresponsive during recovery), matching amdgpu_userq_cleanup().
+		 */
+		down_read(&adev->reset_domain->sem);
 		r = amdgpu_userq_map_helper(queue);
+		up_read(&adev->reset_domain->sem);
 		if (r) {
 			drm_file_err(uq_mgr->file, "Failed to map Queue\n");
 			trace_amdgpu_userq_create_end(queue, r);
-- 
2.49.0

RE: [PATCH] drm/amdgpu/userq: serialize queue map against GPU reset

[Liang, Prike]

AMD General

We may need to ensure some other MES HW accessing without the GPU reset is kicked in concurrently. I'm working on the userq eviction case and figure out how to handle such issue in a general way.

Regards,
      Prike

> -----Original Message-----
> From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> On Behalf Of Jesse
> Zhang
> Sent: Monday, August 3, 2026 5:36 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander <Alexander.Deucher@amd.com>; Koenig, Christian
> <Christian.Koenig@amd.com>; Zhang, Jesse(Jie) <Jesse.Zhang@amd.com>
> Subject: [PATCH] drm/amdgpu/userq: serialize queue map against GPU reset
>
> Creating a user queue can race with a GPU reset. While recovery holds
> reset_domain->sem for write, MES is unresponsive, so the ADD_QUEUE from
> amdgpu_userq_map_helper() times out (-110) and an otherwise valid queue create
> fails:
>
>   amdgpu: MES(0) failed to respond to msg=ADD_QUEUE
>   [drm:mes_userq_map [amdgpu]] *ERROR* Failed to map queue in HW, err (-110)
>   amdgpu: [drm] *ERROR* ... Failed to map Queue
>   amdgpu: [drm] *ERROR* ... Failed to create usermode queue
>
> Take reset_domain->sem for read around the map so it runs only once MES is back
> up. This mirrors amdgpu_userq_cleanup() and honors the userq_mutex ->
> reset_domain->sem order; the reset path never takes userq_mutex, so there is no
> deadlock.
>
> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> index 652599f08990..770635ab5298 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> @@ -745,7 +745,12 @@ amdgpu_userq_create(struct drm_file *filp, union
> drm_amdgpu_userq *args)
>       if (!adev->userq_halt_for_enforce_isolation ||
>           ((queue->queue_type != AMDGPU_HW_IP_GFX) &&
>            (queue->queue_type != AMDGPU_HW_IP_COMPUTE))) {
> +             /* Serialize the map against an in-progress GPU reset (MES is
> +              * unresponsive during recovery), matching amdgpu_userq_cleanup().
> +              */
> +             down_read(&adev->reset_domain->sem);
>               r = amdgpu_userq_map_helper(queue);
> +             up_read(&adev->reset_domain->sem);
>               if (r) {
>                       drm_file_err(uq_mgr->file, "Failed to map Queue\n");
>                       trace_amdgpu_userq_create_end(queue, r);
> --
> 2.49.0

Re: [PATCH] drm/amdgpu/userq: serialize queue map against GPU reset

[Alex Deucher]

On Mon, Aug 3, 2026 at 6:13 AM Jesse Zhang <Jesse.Zhang@amd.com> wrote:
>
> Creating a user queue can race with a GPU reset. While recovery holds
> reset_domain->sem for write, MES is unresponsive, so the ADD_QUEUE from
> amdgpu_userq_map_helper() times out (-110) and an otherwise valid queue
> create fails:
>
>   amdgpu: MES(0) failed to respond to msg=ADD_QUEUE
>   [drm:mes_userq_map [amdgpu]] *ERROR* Failed to map queue in HW, err (-110)
>   amdgpu: [drm] *ERROR* ... Failed to map Queue
>   amdgpu: [drm] *ERROR* ... Failed to create usermode queue
>
> Take reset_domain->sem for read around the map so it runs only once MES
> is back up. This mirrors amdgpu_userq_cleanup() and honors the
> userq_mutex -> reset_domain->sem order; the reset path never takes
> userq_mutex, so there is no deadlock.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

>
> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> index 652599f08990..770635ab5298 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> @@ -745,7 +745,12 @@ amdgpu_userq_create(struct drm_file *filp, union drm_amdgpu_userq *args)
>         if (!adev->userq_halt_for_enforce_isolation ||
>             ((queue->queue_type != AMDGPU_HW_IP_GFX) &&
>              (queue->queue_type != AMDGPU_HW_IP_COMPUTE))) {
> +               /* Serialize the map against an in-progress GPU reset (MES is
> +                * unresponsive during recovery), matching amdgpu_userq_cleanup().
> +                */
> +               down_read(&adev->reset_domain->sem);
>                 r = amdgpu_userq_map_helper(queue);
> +               up_read(&adev->reset_domain->sem);
>                 if (r) {
>                         drm_file_err(uq_mgr->file, "Failed to map Queue\n");
>                         trace_amdgpu_userq_create_end(queue, r);
> --
> 2.49.0
>

Re: [PATCH] drm/amdgpu/userq: serialize queue map against GPU reset

[Christian König]

On 8/3/26 11:35, Jesse Zhang wrote:
> Creating a user queue can race with a GPU reset. While recovery holds
> reset_domain->sem for write, MES is unresponsive, so the ADD_QUEUE from
> amdgpu_userq_map_helper() times out (-110) and an otherwise valid queue
> create fails:
> 
>   amdgpu: MES(0) failed to respond to msg=ADD_QUEUE
>   [drm:mes_userq_map [amdgpu]] *ERROR* Failed to map queue in HW, err (-110)
>   amdgpu: [drm] *ERROR* ... Failed to map Queue
>   amdgpu: [drm] *ERROR* ... Failed to create usermode queue
> 
> Take reset_domain->sem for read around the map so it runs only once MES
> is back up. This mirrors amdgpu_userq_cleanup() and honors the
> userq_mutex -> reset_domain->sem order; the reset path never takes
> userq_mutex, so there is no deadlock.
> 
> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>

Acked-by: Christian König <christian.koenig@amd.com>

Please also loop in Sunil on such patches.

Thanks,
Christian.

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> index 652599f08990..770635ab5298 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> @@ -745,7 +745,12 @@ amdgpu_userq_create(struct drm_file *filp, union drm_amdgpu_userq *args)
>  	if (!adev->userq_halt_for_enforce_isolation ||
>  	    ((queue->queue_type != AMDGPU_HW_IP_GFX) &&
>  	     (queue->queue_type != AMDGPU_HW_IP_COMPUTE))) {
> +		/* Serialize the map against an in-progress GPU reset (MES is
> +		 * unresponsive during recovery), matching amdgpu_userq_cleanup().
> +		 */
> +		down_read(&adev->reset_domain->sem);
>  		r = amdgpu_userq_map_helper(queue);
> +		up_read(&adev->reset_domain->sem);
>  		if (r) {
>  			drm_file_err(uq_mgr->file, "Failed to map Queue\n");
>  			trace_amdgpu_userq_create_end(queue, r);

Re: [PATCH] drm/amdgpu/userq: serialize queue map against GPU reset

[Lazar, Lijo]

On 03-Aug-26 3:05 PM, Jesse Zhang wrote:
> Creating a user queue can race with a GPU reset. While recovery holds
> reset_domain->sem for write, MES is unresponsive, so the ADD_QUEUE from
> amdgpu_userq_map_helper() times out (-110) and an otherwise valid queue
> create fails:
> 
>    amdgpu: MES(0) failed to respond to msg=ADD_QUEUE
>    [drm:mes_userq_map [amdgpu]] *ERROR* Failed to map queue in HW, err (-110)
>    amdgpu: [drm] *ERROR* ... Failed to map Queue
>    amdgpu: [drm] *ERROR* ... Failed to create usermode queue
> 
> Take reset_domain->sem for read around the map so it runs only once MES
> is back up. This mirrors amdgpu_userq_cleanup() and honors the
> userq_mutex -> reset_domain->sem order; the reset path never takes
> userq_mutex, so there is no deadlock.
> 
> Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> index 652599f08990..770635ab5298 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
> @@ -745,7 +745,12 @@ amdgpu_userq_create(struct drm_file *filp, union drm_amdgpu_userq *args)
>   	if (!adev->userq_halt_for_enforce_isolation ||
>   	    ((queue->queue_type != AMDGPU_HW_IP_GFX) &&
>   	     (queue->queue_type != AMDGPU_HW_IP_COMPUTE))) {
> +		/* Serialize the map against an in-progress GPU reset (MES is
> +		 * unresponsive during recovery), matching amdgpu_userq_cleanup().
> +		 */
> +		down_read(&adev->reset_domain->sem);

If a reset is ongoing and a userq operation comes in the middle, there 
is no need to wait till reset semaphore is available. The ongoing 
process i going to terminate sooner or later after the reset.

This should only try to acquire the lock and return an error if not able to.

Thanks,
Lijo

>   		r = amdgpu_userq_map_helper(queue);
> +		up_read(&adev->reset_domain->sem);
>   		if (r) {
>   			drm_file_err(uq_mgr->file, "Failed to map Queue\n");
>   			trace_amdgpu_userq_create_end(queue, r);