lima:sched: fix memory leak on job free

Running kmscube for a long time causes the system to run out of memory until the kmscube process is killed. Using kmemleak, there is a large number of memory leaks reported every few seconds:

[ 500.423055] kmemleak: 15763 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [ 567.182109] kmemleak: 15705 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [ 633.880363] kmemleak: 15688 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

The reported leaks look like the following:

unreferenced object 0xeac2c3c0 (size 184): comm "kmscube", pid 134, jiffies 4294945819 (age 102.290s) hex dump (first 32 bytes): 01 00 00 00 9c e0 05 bf 00 00 00 00 00 00 00 00 ................ d0 c3 c2 ea d0 c3 c2 ea 54 c4 c2 ea 00 00 00 00 ........T....... backtrace: [<13ada39d>] drm_sched_job_init+0x4c/0x160 [gpu_sched] [<940899e1>] lima_sched_task_init+0x10/0x2c [lima] [] lima_gem_submit+0x19c/0x6e4 [lima] [<92131350>] lima_ioctl_gem_submit+0x328/0x3c4 [lima] [] drm_ioctl_kernel+0x84/0xe4 [<5caaff77>] drm_ioctl+0x2bc/0x3bc [] do_vfs_ioctl+0xb0/0xa00 [] ksys_ioctl+0x34/0x58 [] ret_fast_syscall+0x0/0x28 [] 0xbefff894 [] 0xffffffff

lima seems to never trigger the deallocation of the "s_fence" drm_sched_fence, because it never decreases its reference count after the job is run. By decreasing it in lima_sched_free_job, the memory leaks are no longer reported.

Signed-off-by: Erico Nunes nunes.erico@gmail.com