From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Don't clobber crtc->fb when
 queue_flip fails
Date: Fri, 22 Feb 2013 16:36:38 +0200
Message-ID: <20130222143638.GO4469@intel.com>
References: <1361535444-14625-1-git-send-email-ville.syrjala@linux.intel.com>
 <20130222133135.GB23278@cantiga.alporthouse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Return-path: <stable-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20130222133135.GB23278@cantiga.alporthouse.com>
Sender: stable-owner@vger.kernel.org
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
List-Id: intel-gfx@lists.freedesktop.org

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@linux.intel.c=
om wrote:
> > From: Ville Syrj=E4l=E4 <ville.syrjala@linux.intel.com>
> >=20
> > Point crtc->fb the the new framebuffer only after we know that the =
flip
> > was succesfully queued.
> >=20
> > While at it, move the intel_fb and obj assignments a bit close to w=
here
> > they're used.
> >=20
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Ville Syrj=E4l=E4 <ville.syrjala@linux.intel.com>
>=20
> 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.

But if you prefer the set/restore approach I'll send out a version
doing that.

--=20
Ville Syrj=E4l=E4
Intel OTC