Leaking fences

[Thierry Reding]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141016/ab3531f7/attachment-0001.sig>