Am 17.05.2018 um 12:03 schrieb Emily Deng:
To free the fence from the amdgpu_fence_slab, need twice call_rcu, to avoid
the amdgpu_fence_slab_fini call kmem_cache_destroy(amdgpu_fence_slab) before
kmem_cache_free(amdgpu_fence_slab, fence), add rcu_barrier after
The kmem_cache_free(amdgpu_fence_slab, fence)'s call trace as below:
call_rcu(&f->rcu, amdgpu_fence_free) ->
v2:put the barrier before the kmem_cache_destroy
Signed-off-by: Emily Deng <emily.d...@amd.com>
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 39ec6b8..42be65b 100644
@@ -69,6 +69,7 @@ int amdgpu_fence_slab_init(void)
Well, you should have noted that there is already an rcu_barrier here
and adding another one shouldn't have any additional effect. So your
explanation and the proposed solution doesn't make to much sense.
I think the problem you run into is rather that the fence is reference
counted and might live longer than the module who created it.
Complicated issue, one possible solution would be to release
fence->parent earlier in the scheduler fence but that doesn't sound like
a general purpose solution.
amd-gfx mailing list