[Intel-gfx] [PATCH] drm/i915: Don't clobber crtc->fb when queue_flip fails
Chris Wilson
chris at chris-wilson.co.uk
Fri Feb 22 15:41:10 CET 2013
On Fri, Feb 22, 2013 at 04:36:38PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 22, 2013 at 01:31:35PM +0000, Chris Wilson wrote:
> > On Fri, Feb 22, 2013 at 02:17:24PM +0200, ville.syrjala at linux.intel.com wrote:
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > >
> > > Point crtc->fb the the new framebuffer only after we know that the flip
> > > was succesfully queued.
> > >
> > > While at it, move the intel_fb and obj assignments a bit close to where
> > > they're used.
> > >
> > > Cc: stable at vger.kernel.org
> > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >
> > Hmm, that exposes us to a FlipDone interrupt seeing the old crtc->fb.
> > That looks safe enough, but can you see how ugly restoring the old_fb
> > looks in comparison?
>
> I don't think anyone should be poking at crtc->fb w/o holding the crtc
> mutex. Except that intel_update_fbc() actually does. That thing would
> appear to be just broken since it crawls around in the crtc state w/o
> proper protection. The fb could even disappear from under it.
You'll find not a lot of argument from me here, just suggesting that we
avoid the semantic change unless we are confident there are no
surprises.
> But if you prefer the set/restore approach I'll send out a version
> doing that.
I think I would prefer that approach for stable@
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list