linux_dsm_epyc7002/drivers/gpu/drm/amd/scheduler
Christian König e284022163 drm/amdgpu: fix incorrect mutex usage v3
Before this patch the scheduler fence was created when we push the job
into the queue, so we could only get the fence after pushing it.

The mutex now was necessary to prevent the thread pushing the jobs to
the hardware from running faster than the thread pushing the jobs into
the queue.

Otherwise the thread pushing jobs into the queue would have accessed
possible freed up memory when it tries to get a reference to the fence.

So what you get in the end is thread A:
mutex_lock(&job->lock);
...
Kick of thread B.
...
mutex_unlock(&job->lock);

And thread B:
mutex_lock(&job->lock);
....
mutex_unlock(&job->lock);
kfree(job);

I'm actually not sure if I'm still up to date on this, but this usage
pattern used to be not allowed with mutexes. See here as well
https://lwn.net/Articles/575460/.

v2: remove unrelated changes, fix missing owner
v3: rebased, add more commit message

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16 11:05:58 -05:00
..
gpu_sched_trace.h drm/amdgpu: add command submission workflow tracepoint 2015-11-16 11:05:57 -05:00
gpu_scheduler.c drm/amdgpu: fix incorrect mutex usage v3 2015-11-16 11:05:58 -05:00
gpu_scheduler.h drm/amdgpu: fix incorrect mutex usage v3 2015-11-16 11:05:58 -05:00
sched_fence.c drm/amd: add kmem cache for sched fence 2015-11-16 11:05:51 -05:00