All of 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>
Subject: Re: [PATCH v6 07/11] drm/amdgpu: validate userq's last fence prior to destroying
Date: Tue, 15 Jul 2025 14:15:10 +0200	[thread overview]
Message-ID: <0c83e6be-66ec-4dba-bb8e-c00e6fab7541@amd.com> (raw)
In-Reply-To: <DS7PR12MB600519342AB474F08F21DC0EFB57A@DS7PR12MB6005.namprd12.prod.outlook.com>

On 15.07.25 13:50, Liang, Prike wrote:
> [Public]
> 
> Regards,
>       Prike
> 
>> -----Original Message-----
>> From: Koenig, Christian <Christian.Koenig@amd.com>
>> Sent: Friday, July 11, 2025 8:13 PM
>> To: Liang, Prike <Prike.Liang@amd.com>; amd-gfx@lists.freedesktop.org
>> Cc: Deucher, Alexander <Alexander.Deucher@amd.com>
>> Subject: Re: [PATCH v6 07/11] drm/amdgpu: validate userq's last fence prior to
>> destroying
>>
>> On 11.07.25 11:39, Prike Liang wrote:
>>> The userq requires validating queue status before destroying it, if
>>> user tries to destroy a busy userq by IOCTL then the driver should
>>> report an error for this illegal usage.
>>
>> Clear NAK, destroying a busy userqueue is perfectly valid!
> Yes, the firmware should handle such case something like as preempting the queue.
> If we directly unmap a hang queue and may further cause the MES firmware hang up,
> so, do we need to detect the hang userq here by checking the userq fence status and reset the hang queue before further performs the unmap queue?

No, waiting for the last fence should be perfectly sufficient since the hang detection is separate from this.

BTW please remove the 100ms timeout here, we should wait forever or until the hang detection has suspended the queue and signaled the fence with an error.

Regards,
Christian.


> 
>> Regards,
>> Christian.
>>
>>>
>>> Signed-off-by: Prike Liang <Prike.Liang@amd.com>
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 15 ++++++++++++---
>>>  1 file changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
>>> index 81fbb00b6d91..bcbe8d3f66ed 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
>>> @@ -281,7 +281,7 @@ amdgpu_userq_map_helper(struct amdgpu_userq_mgr
>> *uq_mgr,
>>>     return r;
>>>  }
>>>
>>> -static void
>>> +static int
>>>  amdgpu_userq_wait_for_last_fence(struct amdgpu_userq_mgr *uq_mgr,
>>>                              struct amdgpu_usermode_queue *queue)  { @@ -
>> 290,10 +290,14 @@
>>> amdgpu_userq_wait_for_last_fence(struct amdgpu_userq_mgr *uq_mgr,
>>>
>>>     if (f && !dma_fence_is_signaled(f)) {
>>>             ret = dma_fence_wait_timeout(f, true, msecs_to_jiffies(100));
>>> -           if (ret <= 0)
>>> +           if (ret <= 0) {
>>>                     drm_file_err(uq_mgr->file, "Timed out waiting for
>> fence=%llu:%llu\n",
>>>                                  f->context, f->seqno);
>>> +                   return -ETIMEDOUT;
>>> +           }
>>>     }
>>> +
>>> +   return 0;
>>>  }
>>>
>>>  static void
>>> @@ -509,7 +513,12 @@ amdgpu_userq_destroy(struct drm_file *filp, int
>> queue_id)
>>>             mutex_unlock(&uq_mgr->userq_mutex);
>>>             return -EINVAL;
>>>     }
>>> -   amdgpu_userq_wait_for_last_fence(uq_mgr, queue);
>>> +
>>> +   if (amdgpu_userq_wait_for_last_fence(uq_mgr, queue)) {
>>> +           drm_warn(adev_to_drm(uq_mgr->adev), "Don't destroy a busy
>> userq\n");
>>> +           /* For the fence signal timeout case, it requires resetting the busy
>> queue.*/
>>> +           r = -ETIMEDOUT;
>>> +   }
>>>
>>>     /*
>>>      * At this point the userq obj va should be mapped,
> 


  reply	other threads:[~2025-07-15 12:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-11  9:39 [PATCH v6 01/11] drm/amdgpu: validate userq input args Prike Liang
2025-07-11  9:39 ` [PATCH v6 02/11] drm/amdgpu: validate userq hw unmap status for destroying userq Prike Liang
2025-07-11  9:39 ` [PATCH v6 03/11] drm/amdgpu: rework the userq doorbell object destroy Prike Liang
2025-07-11 12:00   ` Christian König
2025-07-15  8:07     ` Liang, Prike
2025-07-15  8:49       ` Christian König
2025-07-16  7:03         ` Liang, Prike
2025-07-11  9:39 ` [PATCH v6 04/11] drm/amdgpu: validate userq buffer virtual address and size Prike Liang
2025-07-11 12:08   ` Christian König
2025-07-15  8:19     ` Liang, Prike
2025-07-15  8:41       ` Christian König
2025-07-11  9:39 ` [PATCH v6 05/11] drm/amdgpu: add userq object va track helpers Prike Liang
2025-07-11  9:39 ` [PATCH v6 06/11] drm/amdgpu: track the userq bo va for its obj management Prike Liang
2025-07-11 12:11   ` Christian König
2025-07-15 12:05     ` Liang, Prike
2025-07-15 12:17       ` Christian König
2025-07-16  6:54         ` Liang, Prike
2025-07-11  9:39 ` [PATCH v6 07/11] drm/amdgpu: validate userq's last fence prior to destroying Prike Liang
2025-07-11 12:12   ` Christian König
2025-07-15 11:50     ` Liang, Prike
2025-07-15 12:15       ` Christian König [this message]
2025-07-11  9:39 ` [PATCH v6 08/11] drm/amdgpu: clean up the amdgpu_userq_active() Prike Liang
2025-07-11  9:39 ` [PATCH v6 09/11] drm/amdgpu: validate the shared bo for tracking usage size Prike Liang
2025-07-11 12:14   ` Christian König
2025-07-11 13:43     ` Liang, Prike
2025-07-11  9:39 ` [PATCH v6 10/11] drm/amdgpu: validate the queue va for resuming the queue Prike Liang
2025-07-11 12:18   ` Christian König
2025-07-11  9:39 ` [PATCH v6 11/11] drm/amdgpu: validate userq va for GEM unmap Prike Liang

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=0c83e6be-66ec-4dba-bb8e-c00e6fab7541@amd.com \
    --to=christian.koenig@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Prike.Liang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.