Well, I'm at the
# cat /sys/kernel/debug/kmemleak
par of my day.
I guess it's my turn to be "it's a kernel bug!" guy.
f'realz tho...
# grep drm_atomic_helper_commit /sys/kernel/debug/kmemleak | wc -l
51838
Well, this seems like a race condition. If I turn up drm.debug in sysfs, no memory gets leaked. Heisenbugs [sigh]
Turned out there were no locks around the atomic commit so it was only atomic if it page flipping was synchronous. If another commit came in it would clobber the commit obj and/or abandon the completion event. Vendor solution in the unholy fork was to disable async page flipping to a terrible performance hit. But they also actually fixed the bug later. :facepalm:
I wonder how many kernel patches are like "this other party fork is impossible to merge but they fixed this one thing for which I am including the patch" ... or is that... uncouth?
This seems incredible on mainline though. Current theory is ioctl for page flip seems to perhaps be leaking `struct drm_pending_vblank_event` (bleeding kmalloc-64 slabs). Perhaps a missing send_event* ... maybe based on vblank + async combination.