[PATCH 11/11] drm: Fix vblank timestamp races

[Daniel Vetter]

On Tue, Sep 22, 2015 at 03:36:44PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 22, 2015 at 11:10:50AM +0200, Daniel Vetter wrote:
> > On Mon, Sep 14, 2015 at 10:43:52PM +0300, ville.syrjala at linux.intel.com wrote:
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > 
> > > The vblank timestamp ringbuffer only has two entries, so if the
> > > vblank->count is incremented by an even number readers may end up seeing
> > > the new vblank timestamp alongside the old vblank counter value.
> > > 
> > > Fix the problem by storing the vblank counter in a ringbuffer as well,
> > > and always increment the ringbuffer "slot" by one when storing a new
> > > timestamp+counter pair.
> > > 
> > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > 
> > Imo if we bother with this we might as well just switch over to using
> > full-blown seqlocks. They internally use a two-stage update which means
> > race-free even with just one copy of the data we protect. Also more
> > standardized to boot.
> 
> Any volunteers for that? I don't have time to start redoing this right
> now.

I guess we can keep it as a low-hanging thing for now, didn't seem to have
annoyed anyone yet. It should be fairly simple since all the vblank
counter access goes through the 2 functions I created a while back while
polishing the barriers a bit.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch