amd-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: "Khatri, Sunil" <sukhatri@amd.com>,
	Sunil Khatri <sunil.khatri@amd.com>,
	Alex Deucher <alexander.deucher@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH v6 2/8] drm/amdgpu/userq: Fix the mutex_init cleanup for fence_drv_lock
Date: Tue, 19 May 2026 15:52:58 +0200	[thread overview]
Message-ID: <37f7cb2f-4ddf-45da-9c51-9100c9155302@amd.com> (raw)
In-Reply-To: <db639edc-0b5e-4165-9363-43c265a75839@amd.com>



On 5/19/26 15:09, Khatri, Sunil wrote:
> 
> On 19-05-2026 06:08 pm, Christian König wrote:
>> On 5/19/26 13:17, Sunil Khatri wrote:
>>> mutex fence_drv_lock is destroyed in amdgpu_userq_fence_driver_free
>>> also in one of the jump condition mutex_destroy is also called leading
>>> to double mutex_destroy.
>>>
>>> So rearranging the code so amdgpu_userq_fence_driver_free takes care
>>> of the clean up along with mutex_destroy.
>> Please also move amdgpu_userq_fence_driver_free() into amdgpu_userq.c or eventually completely drop it.
>>
>> The cleanup done in there is actually on the queue and not the fence driver
> 
> There is no clear demarcation here, we are doing amdgpu_userq_walk_and_drop_fence_drv and amdgpu_userq_fence_driver_put in the clean up function.  If it's ok we could pick that up later for code
> 
> organization as its mixed use case right now and all the function called from clean up also needs to be pulled in.

Yeah all of that looks pretty mixed up. Maybe we should move the handling more into amdgpu_userq_fence.c, I don't really know what would be cleaner.

Anyway Reviewed-by: Christian König <christian.koenig@amd.com> for this patch at the moment since it is clearly fixing a bug.

Thanks,
Christian.

> 
> Regards
> Sunil Khatri
> 
>>
>> Regards,
>> Christian.
>>
>>> Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
>>> ---
>>>   drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c | 5 ++---
>>>   1 file changed, 2 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
>>> index eedea84c5e0f..3bfb9ae2cb3a 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_userq.c
>>> @@ -748,12 +748,12 @@ amdgpu_userq_create(struct drm_file *filp, union drm_amdgpu_userq *args)
>>>       INIT_DELAYED_WORK(&queue->hang_detect_work,
>>>                 amdgpu_userq_hang_detect_work);
>>>   -    mutex_init(&queue->fence_drv_lock);
>>> -    xa_init_flags(&queue->fence_drv_xa, XA_FLAGS_ALLOC);
>>>       r = amdgpu_userq_fence_driver_alloc(adev, &queue->fence_drv);
>>>       if (r)
>>>           goto free_queue;
>>>   +    xa_init_flags(&queue->fence_drv_xa, XA_FLAGS_ALLOC);
>>> +    mutex_init(&queue->fence_drv_lock);
>>>       /* Make sure the queue can actually run with those virtual addresses. */
>>>       r = amdgpu_bo_reserve(fpriv->vm.root.bo, false);
>>>       if (r)
>>> @@ -844,7 +844,6 @@ amdgpu_userq_create(struct drm_file *filp, union drm_amdgpu_userq *args)
>>>       amdgpu_bo_reserve(fpriv->vm.root.bo, true);
>>>       amdgpu_userq_buffer_vas_list_cleanup(adev, queue);
>>>       amdgpu_bo_unreserve(fpriv->vm.root.bo);
>>> -    mutex_destroy(&queue->fence_drv_lock);
>>>   free_fence_drv:
>>>       amdgpu_userq_fence_driver_free(queue);
>>>   free_queue:


  reply	other threads:[~2026-05-19 13:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19 11:17 [PATCH v6 1/8] drm/amdgpu/userq: Fix doorbell object cleanup of queue Sunil Khatri
2026-05-19 11:17 ` [PATCH v6 2/8] drm/amdgpu/userq: Fix the mutex_init cleanup for fence_drv_lock Sunil Khatri
2026-05-19 12:38   ` Christian König
2026-05-19 13:09     ` Khatri, Sunil
2026-05-19 13:52       ` Christian König [this message]
2026-05-19 11:17 ` [PATCH v6 3/8] drm/amdgpu: simplify return value in amdgpu_userq_get_doorbell_index Sunil Khatri
2026-05-19 12:39   ` Christian König
2026-05-19 11:17 ` [PATCH v6 4/8] drm/amdgpu/userq: clean up wptr_obj along with mqd_destroy Sunil Khatri
2026-05-19 12:43   ` Christian König
2026-05-19 13:10     ` Khatri, Sunil
2026-05-19 11:17 ` [PATCH v6 5/8] drm/amdgpu/userq: add amdgpu_bo_unpin when amdgpu_ttm_alloc_gart fails Sunil Khatri
2026-05-19 13:53   ` Christian König
2026-05-19 11:17 ` [PATCH v6 6/8] drm/amdgpu/userq: reserve root bo without interruption Sunil Khatri
2026-05-19 13:54   ` Christian König
2026-05-19 11:18 ` [PATCH v6 7/8] drm/amdgpu/userq: make sure queue is valid in the hang_detect_work Sunil Khatri
2026-05-19 14:00   ` Christian König
2026-05-19 11:18 ` [PATCH v6 8/8] drm/amdgpu/userq: user array to store userq vas Sunil Khatri
2026-05-19 14:06   ` Christian König
2026-05-19 12:34 ` [PATCH v6 1/8] drm/amdgpu/userq: Fix doorbell object cleanup of queue Christian König

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=37f7cb2f-4ddf-45da-9c51-9100c9155302@amd.com \
    --to=christian.koenig@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=sukhatri@amd.com \
    --cc=sunil.khatri@amd.com \
    /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;
as well as URLs for NNTP newsgroup(s).