[Intel-gfx] [PATCH 1/2] drm: refernce count event->completion

[Daniel Vetter]

On Wed, Dec 21, 2016 at 10:36:41AM +0000, Chris Wilson wrote:
> On Wed, Dec 21, 2016 at 11:23:30AM +0100, Daniel Vetter wrote:
> > When writing the generic nonblocking commit code I assumed that
> > through clever lifetime management I can assure that the completion
> > (stored in drm_crtc_commit) only gets freed after it is completed. And
> > that worked.
> > 
> > I also wanted to make nonblocking helpers resilient against driver
> > bugs, by having timeouts everywhere. And that worked too.
> > 
> > Unfortunately taking boths things together results in oopses :( Well,
> > at least sometimes: What seems to happen is that the drm event hangs
> > around forever stuck in limbo land. The nonblocking helpers eventually
> > time out, move on and release it. Now the bug I tested all this
> > against is drivers that just entirely fail to deliver the vblank
> > events like they should, and in those cases the event is simply
> > leaked. But what seems to happen, at least sometimes, on i915 is that
> > the event is set up correctly, but somohow the vblank fails to fire in
> > time. Which means the event isn't leaked, it's still there waiting for
> > eventually a vblank to fire. That tends to happen when re-enabling the
> > pipe, and then the trap springs and the kernel oopses.
> > 
> > The correct fix here is simply to refcount the crtc commit to make
> > sure that the event sticks around even for drivers which only
> > sometimes fail to deliver vblanks for some arbitrary reasons. Since
> > crtc commits are already refcounted that's easy to do.
> 
> Or make the event a part of the atomic state?

I guess we could do that, but I wanted the most minimal thing for
backporting. And reference-counted atomic state is new, and the patch
would be a bit bigger.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch