On Mon, Oct 24, 2016 at 12:13 PM, Christian König <deathsimple@xxxxxxxxxxx> wrote: > Am 24.10.2016 um 04:25 schrieb zhoucm1: >> >> >> >> On 2016年10月24日 02:31, Grazvydas Ignotas wrote: >>> >>> It's done in amd_sched_hw_job_reset(), but not in normal job processing. >>> Leak reported by CONFIG_SLUB_DEBUG. >>> >>> Signed-off-by: Grazvydas Ignotas <notasas@xxxxxxxxx> >>> --- >>> CONFIG_SLUB_DEBUG reports more leaks related to ioctls, >>> but I was unable to track them down... >>> >>> drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c >>> b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c >>> index 910b8d5..cfb686e 100644 >>> --- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c >>> +++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c >>> @@ -522,6 +522,8 @@ static void amd_sched_process_job(struct fence *f, >>> struct fence_cb *cb) >>> trace_amd_sched_process_job(s_fence); >>> fence_put(&s_fence->finished); >>> + fence_put(s_fence->parent); >> >> If I remember correctly, parent was put in sched fence release. > > > Yes, exactly. It's only released in amd_sched_hw_job_reset() because we want > to assign a new parent fence. Well then it doesn't work, SLUB_DEBUG detects leaks on teardown, and with my patch they're gone. Perhaps the problem is that when new parent fence is assigned, the old one is not put? I won't be able to check until the weekend, so if anybody else can do it, please go ahead. Gražvydas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
