From: "Christian König" <christian.koenig@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>,
amd-gfx@lists.freedesktop.org
Cc: Alex Deucher <alexander.deucher@amd.com>
Subject: Re: [RFC 3/3] drm/amdgpu: Add locking to amdgpu_ctx_mgr_entity_fini()
Date: Tue, 20 May 2025 09:39:48 +0200 [thread overview]
Message-ID: <71accc22-29d1-47ff-909e-e8eb2bdd528a@amd.com> (raw)
In-Reply-To: <20250519163713.11367-4-tvrtko.ursulin@igalia.com>
On 5/19/25 18:37, Tvrtko Ursulin wrote:
> Amdgpu_ctx_mgr_entity_fini() walks the context IDR unlocked so question is
> could it in theory see a stale entry and attempt to destroy the
> drm_sched_entity twice?
No, when this function is called when the file descriptor is freed up.
So there should never ever be any concurrent user of this.
> Problem is I have hit this on a KASAN enabled kernel only _once_ and never
> since. In that case it reported amdgpu_ctx_ioctl() had freed the entity
> already which would mean the question is could we possibly go through the
> mutex_unlock() on one CPU, and another CPU to follow immediately with
> file->release (DRM postclose) and see the stale entry.
Mhm, it would basically mean that the file descriptor can be closed while some IOCTL on it is still ongoing.
I think that this would be extremely ugly and should never ever happen in the first place. Adding the mutex just band aids the issue, but not really fixes it.
> Throwing it out there not to forget about it, since I have manage to
> lose the KASAN trace already..
If you manage to trigger that again please send it to me ASAP.
Thanks,
Christian.
>
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian König <christian.koenig@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> index 85567d0d9545..95b005ed839e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> @@ -927,6 +927,7 @@ static void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr *mgr)
>
> idp = &mgr->ctx_handles;
>
> + mutex_lock(&mgr->lock);
> idr_for_each_entry(idp, ctx, id) {
> if (kref_read(&ctx->refcount) != 1) {
> DRM_ERROR("ctx %p is still alive\n", ctx);
> @@ -945,6 +946,7 @@ static void amdgpu_ctx_mgr_entity_fini(struct amdgpu_ctx_mgr *mgr)
> }
> }
> }
> + mutex_unlock(&mgr->lock);
> }
>
> void amdgpu_ctx_mgr_fini(struct amdgpu_ctx_mgr *mgr)
next prev parent reply other threads:[~2025-05-20 7:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-19 16:37 [RFC 0/3] Potential context entity destroy race Tvrtko Ursulin
2025-05-19 16:37 ` [RFC 1/3] drm/amdgpu: Make amdgpu_ctx_mgr_entity_fini static Tvrtko Ursulin
2025-05-20 7:31 ` Christian König
2025-05-19 16:37 ` [RFC 2/3] drm/amdgpu: Remove duplicated "context still alive" check Tvrtko Ursulin
2025-05-20 7:34 ` Christian König
2025-05-20 14:17 ` Alex Deucher
2025-05-19 16:37 ` [RFC 3/3] drm/amdgpu: Add locking to amdgpu_ctx_mgr_entity_fini() Tvrtko Ursulin
2025-05-20 7:39 ` Christian König [this message]
2025-05-20 7:50 ` Tvrtko Ursulin
2025-05-20 8:40 ` Christian König
2025-05-20 16:23 ` Tvrtko Ursulin
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=71accc22-29d1-47ff-909e-e8eb2bdd528a@amd.com \
--to=christian.koenig@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=tvrtko.ursulin@igalia.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 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.