* mutex_destroy in amdgpu_ctx_fini()
@ 2016-09-29 11:18 StDenis, Tom
[not found] ` <CY4PR12MB1768BBD9F3498EA5EB29C317F7CE0-rpdhrqHFk06yjjPBNVDk/QdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
0 siblings, 1 reply; 3+ messages in thread
From: StDenis, Tom @ 2016-09-29 11:18 UTC (permalink / raw)
To: amd-gfx list
In this block of code I'm wondering if the mutex_destroy should be hoisted out of the inner loop?
static void amdgpu_ctx_fini(struct amdgpu_ctx *ctx)
{
struct amdgpu_device *adev = ctx->adev;
unsigned i, j;
if (!adev)
return;
for (i = 0; i < AMDGPU_MAX_RINGS; ++i)
for (j = 0; j < amdgpu_sched_jobs; ++j) {
fence_put(ctx->rings[i].fences[j]);
mutex_destroy(&ctx->rings[i].sem_lock);
}
Cheers,
Tom
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 3+ messages in thread[parent not found: <CY4PR12MB1768BBD9F3498EA5EB29C317F7CE0-rpdhrqHFk06yjjPBNVDk/QdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>]
* Re: mutex_destroy in amdgpu_ctx_fini() [not found] ` <CY4PR12MB1768BBD9F3498EA5EB29C317F7CE0-rpdhrqHFk06yjjPBNVDk/QdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org> @ 2016-09-29 11:33 ` Christian König 2016-09-30 3:28 ` zhoucm1 1 sibling, 0 replies; 3+ messages in thread From: Christian König @ 2016-09-29 11:33 UTC (permalink / raw) To: StDenis, Tom, amd-gfx list At least of hand that strongly looks like a bug. Probably doesn't do much harm cause mutex_destroy() is mostly for lockdep annotation, but still should be fixed. Christian. Am 29.09.2016 um 13:18 schrieb StDenis, Tom: > In this block of code I'm wondering if the mutex_destroy should be hoisted out of the inner loop? > > static void amdgpu_ctx_fini(struct amdgpu_ctx *ctx) > { > struct amdgpu_device *adev = ctx->adev; > unsigned i, j; > > > if (!adev) > return; > > > for (i = 0; i < AMDGPU_MAX_RINGS; ++i) > for (j = 0; j < amdgpu_sched_jobs; ++j) { > fence_put(ctx->rings[i].fences[j]); > mutex_destroy(&ctx->rings[i].sem_lock); > } > > > Cheers, > Tom > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: mutex_destroy in amdgpu_ctx_fini() [not found] ` <CY4PR12MB1768BBD9F3498EA5EB29C317F7CE0-rpdhrqHFk06yjjPBNVDk/QdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org> 2016-09-29 11:33 ` Christian König @ 2016-09-30 3:28 ` zhoucm1 1 sibling, 0 replies; 3+ messages in thread From: zhoucm1 @ 2016-09-30 3:28 UTC (permalink / raw) To: StDenis, Tom, amd-gfx list Good catch, Could you make a patch? Thanks, David Zhou On 2016年09月29日 19:18, StDenis, Tom wrote: > In this block of code I'm wondering if the mutex_destroy should be hoisted out of the inner loop? > > static void amdgpu_ctx_fini(struct amdgpu_ctx *ctx) > { > struct amdgpu_device *adev = ctx->adev; > unsigned i, j; > > > if (!adev) > return; > > > for (i = 0; i < AMDGPU_MAX_RINGS; ++i) > for (j = 0; j < amdgpu_sched_jobs; ++j) { > fence_put(ctx->rings[i].fences[j]); > mutex_destroy(&ctx->rings[i].sem_lock); > } > > > Cheers, > Tom > _______________________________________________ > amd-gfx mailing list > amd-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-09-30 3:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-09-29 11:18 mutex_destroy in amdgpu_ctx_fini() StDenis, Tom
[not found] ` <CY4PR12MB1768BBD9F3498EA5EB29C317F7CE0-rpdhrqHFk06yjjPBNVDk/QdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
2016-09-29 11:33 ` Christian König
2016-09-30 3:28 ` zhoucm1
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.