* [PATCH] drm/amdgpu: fix sched fence slab teardown
@ 2016-10-23 18:31 Grazvydas Ignotas
2016-10-24 2:34 ` zhoucm1
0 siblings, 1 reply; 4+ messages in thread
From: Grazvydas Ignotas @ 2016-10-23 18:31 UTC (permalink / raw)
To: dri-devel, amd-gfx
To free fences, call_rcu() is used, which calls amd_sched_fence_free()
after a grace period. During teardown, there is no guarantee all
callbacks have finished, so sched_fence_slab may be destroyed before
all fences have been freed. If we are lucky, this results in some slab
warnings, if not, we get a crash in one of rcu threads because callback
is called after amdgpu has already been unloaded.
Fix it with a rcu_barrier().
Fixes: 189e0fb76304 ("drm/amdgpu: RCU protected amd_sched_fence_release")
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
index 963a24d..910b8d5 100644
--- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
@@ -645,6 +645,7 @@ void amd_sched_fini(struct amd_gpu_scheduler *sched)
{
if (sched->thread)
kthread_stop(sched->thread);
+ rcu_barrier();
if (atomic_dec_and_test(&sched_fence_slab_ref))
kmem_cache_destroy(sched_fence_slab);
}
--
2.7.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] drm/amdgpu: fix sched fence slab teardown
2016-10-23 18:31 [PATCH] drm/amdgpu: fix sched fence slab teardown Grazvydas Ignotas
@ 2016-10-24 2:34 ` zhoucm1
2016-10-24 9:06 ` Christian König
0 siblings, 1 reply; 4+ messages in thread
From: zhoucm1 @ 2016-10-24 2:34 UTC (permalink / raw)
To: Grazvydas Ignotas, dri-devel, amd-gfx
Acked-by: Chunming Zhou <david1.zhou@amd.com>
On 2016年10月24日 02:31, Grazvydas Ignotas wrote:
> To free fences, call_rcu() is used, which calls amd_sched_fence_free()
> after a grace period. During teardown, there is no guarantee all
> callbacks have finished, so sched_fence_slab may be destroyed before
> all fences have been freed. If we are lucky, this results in some slab
> warnings, if not, we get a crash in one of rcu threads because callback
> is called after amdgpu has already been unloaded.
>
> Fix it with a rcu_barrier().
>
> Fixes: 189e0fb76304 ("drm/amdgpu: RCU protected amd_sched_fence_release")
> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
> ---
> drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> index 963a24d..910b8d5 100644
> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
> @@ -645,6 +645,7 @@ void amd_sched_fini(struct amd_gpu_scheduler *sched)
> {
> if (sched->thread)
> kthread_stop(sched->thread);
> + rcu_barrier();
> if (atomic_dec_and_test(&sched_fence_slab_ref))
> kmem_cache_destroy(sched_fence_slab);
> }
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] drm/amdgpu: fix sched fence slab teardown
2016-10-24 2:34 ` zhoucm1
@ 2016-10-24 9:06 ` Christian König
[not found] ` <bde776d0-0044-5742-ae1a-1de2a4cf5faa-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Christian König @ 2016-10-24 9:06 UTC (permalink / raw)
To: zhoucm1, Grazvydas Ignotas, dri-devel, amd-gfx
Reviewed-by: Christian König <christian.koenig@amd.com>
Am 24.10.2016 um 04:34 schrieb zhoucm1:
> Acked-by: Chunming Zhou <david1.zhou@amd.com>
>
> On 2016年10月24日 02:31, Grazvydas Ignotas wrote:
>> To free fences, call_rcu() is used, which calls amd_sched_fence_free()
>> after a grace period. During teardown, there is no guarantee all
>> callbacks have finished, so sched_fence_slab may be destroyed before
>> all fences have been freed. If we are lucky, this results in some slab
>> warnings, if not, we get a crash in one of rcu threads because callback
>> is called after amdgpu has already been unloaded.
>>
>> Fix it with a rcu_barrier().
>>
>> Fixes: 189e0fb76304 ("drm/amdgpu: RCU protected
>> amd_sched_fence_release")
>> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
>> ---
>> drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> index 963a24d..910b8d5 100644
>> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>> @@ -645,6 +645,7 @@ void amd_sched_fini(struct amd_gpu_scheduler *sched)
>> {
>> if (sched->thread)
>> kthread_stop(sched->thread);
>> + rcu_barrier();
>> if (atomic_dec_and_test(&sched_fence_slab_ref))
>> kmem_cache_destroy(sched_fence_slab);
>> }
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] drm/amdgpu: fix sched fence slab teardown
[not found] ` <bde776d0-0044-5742-ae1a-1de2a4cf5faa-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
@ 2016-10-24 16:08 ` Alex Deucher
0 siblings, 0 replies; 4+ messages in thread
From: Alex Deucher @ 2016-10-24 16:08 UTC (permalink / raw)
To: Christian König; +Cc: zhoucm1, amd-gfx list, Maling list - DRI developers
On Mon, Oct 24, 2016 at 5:06 AM, Christian König
<deathsimple@vodafone.de> wrote:
> Reviewed-by: Christian König <christian.koenig@amd.com>
>
>
> Am 24.10.2016 um 04:34 schrieb zhoucm1:
>>
>> Acked-by: Chunming Zhou <david1.zhou@amd.com>
>>
>> On 2016年10月24日 02:31, Grazvydas Ignotas wrote:
>>>
>>> To free fences, call_rcu() is used, which calls amd_sched_fence_free()
>>> after a grace period. During teardown, there is no guarantee all
>>> callbacks have finished, so sched_fence_slab may be destroyed before
>>> all fences have been freed. If we are lucky, this results in some slab
>>> warnings, if not, we get a crash in one of rcu threads because callback
>>> is called after amdgpu has already been unloaded.
>>>
>>> Fix it with a rcu_barrier().
>>>
>>> Fixes: 189e0fb76304 ("drm/amdgpu: RCU protected amd_sched_fence_release")
>>> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
>>> ---
>>> drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>>> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>>> index 963a24d..910b8d5 100644
>>> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>>> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
>>> @@ -645,6 +645,7 @@ void amd_sched_fini(struct amd_gpu_scheduler *sched)
>>> {
>>> if (sched->thread)
>>> kthread_stop(sched->thread);
>>> + rcu_barrier();
>>> if (atomic_dec_and_test(&sched_fence_slab_ref))
>>> kmem_cache_destroy(sched_fence_slab);
>>> }
>>
Applied. thanks!
Alex
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-10-24 16:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-23 18:31 [PATCH] drm/amdgpu: fix sched fence slab teardown Grazvydas Ignotas
2016-10-24 2:34 ` zhoucm1
2016-10-24 9:06 ` Christian König
[not found] ` <bde776d0-0044-5742-ae1a-1de2a4cf5faa-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2016-10-24 16:08 ` Alex Deucher
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).