Hi,
While investigating something completely unrelated, I came across this:
# cat /sys/kernel/debug/kmemleak unreferenced object 0xec934200 (size 512): comm "triangle", pid 186, jiffies 4294949362 (age 199.440s) hex dump (first 32 bytes): 08 00 08 00 ad 4e ad de ff ff ff ff ff ff ff ff .....N.......... a8 b5 1a c1 38 1a d4 c0 00 00 00 00 4c 73 9d c0 ....8.......Ls.. backtrace: [<c00ee72c>] kmem_cache_alloc+0xf4/0x174 [<c03edcc8>] nv84_fence_context_new+0x58/0x170 [<c03ee564>] nvc0_fence_context_new+0xc/0x34 [<c03e2d3c>] nouveau_channel_new+0x374/0x730 [<c03eb6d4>] nouveau_abi16_ioctl_channel_alloc+0x148/0x37c [<c0327620>] drm_ioctl+0x1d4/0x50c [<c03e0eac>] nouveau_drm_ioctl+0x58/0xa4 [<c0107498>] do_vfs_ioctl+0x3f0/0x614 [<c01076f0>] SyS_ioctl+0x34/0x5c [<c000e8e0>] ret_fast_syscall+0x0/0x30 [<ffffffff>] 0xffffffff
That's recorded by kmemleak after running a the "triangle" test program, which is essentially just a program that renders a smooth-shaded triangle on gk20a and displays it on Tegra DRM. Anyway, I'm pretty sure the workload isn't anything special, so I suspect that this is happening for other programs as well.
It seems like this could be due to somebody holding a reference to the fence. Perhaps this is just kmemleak getting confused, but I thought I'd bring it up, perhaps somebody has an idea about what's going on here.
Thierry