From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH v2 1/2] drm/i915: fix possible refcount leak when resetting forcewake Date: Fri, 6 Jun 2014 22:15:32 +0200 Message-ID: <20140606201532.GV7416@phenom.ffwll.local> References: <1402048779-14902-1-git-send-email-imre.deak@intel.com> <1402052677-19607-1-git-send-email-imre.deak@intel.com> <20140606110843.GF22214@nuc-i3427.alporthouse.com> <20140606174619.GS7416@phenom.ffwll.local> <1402079906.4193.11.camel@ideak-mobl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by gabe.freedesktop.org (Postfix) with ESMTP id 117E16EACE for ; Fri, 6 Jun 2014 13:15:36 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id bs8so1583084wib.3 for ; Fri, 06 Jun 2014 13:15:36 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1402079906.4193.11.camel@ideak-mobl> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Imre Deak Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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 > > > Reviewed-by: Chris Wilson > > > > 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 once we set the autoresume delay to something more sane (100ms maybe, patches anyone?) we definitely need this patch here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch