[Intel-gfx] [PATCH v2 1/2] drm/i915: fix possible refcount leak when resetting forcewake

[Imre Deak]

On Fri, 2014-06-06 at 22:35 +0200, Daniel Vetter wrote:
> On Fri, Jun 06, 2014 at 11:19:28PM +0300, Imre Deak wrote:
> > On Fri, 2014-06-06 at 22:15 +0200, Daniel Vetter wrote:
> > > On Fri, Jun 06, 2014 at 09:38:26PM +0300, Imre Deak wrote:
> > > > On Fri, 2014-06-06 at 19:46 +0200, Daniel Vetter wrote:
> > > > > On Fri, Jun 06, 2014 at 12:08:43PM +0100, Chris Wilson wrote:
> > > > > > On Fri, Jun 06, 2014 at 02:04:37PM +0300, Imre Deak wrote:
> > > > > > > If the timer putting the last forcewake refcount was pending and we
> > > > > > > canceled it, we'll leak the corresponding forcewake and RPM references.
> > > > > > > 
> > > > > > > v2:
> > > > > > > - do the ptr casting at the caller instead of adding a separate helper
> > > > > > >   for this (Chris)
> > > > > > > 
> > > > > > > Signed-off-by: Imre Deak <imre.deak at intel.com>
> > > > > > Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > > > 
> > > > > Both patches merged to dinq (Chris clarified on irc that his r-b is for
> > > > > both).
> > > > >
> > > > > Since this only blows up in a super-contrived testcase I don't
> > > > > think this is material for -fixes.
> > > > 
> > > > Note that the issue fixed by 1/2 could also happen normally, though the
> > > > window for race is small. One scenario would be runtime resume
> > > > ->deferred rps_enable followed directly by system suspend or gpu reset.
> > > 
> > > The default runtime pm autosuspend delay is longer than the delayed rps
> > > enable, so for all practical purposes I think this is impossible.
> > 
> > But system suspend is not affected by that delay, it can happen right
> > after a runtime resume.
> 
> Until we drop the forcewake time we hold a runtime pm ref. So I don't
> think there's an issue either on that side of the system resume ... Or do
> I miss something?

Let's say that forcewake timer is pending, holding the runtime pm ref.
System suspend is called - it's not prevented by either this ref or the
above autosuspend delay - in the suspend handler we eventually call
force_wake_reset which cancels the timer, leaking the runtime pm ref.

--Imre