From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH 2/2] drm/i915: Unpin stolen pages Date: Sat, 1 Jun 2013 00:51:02 +0100 Message-ID: <20130531235102.GA1097@cantiga.alporthouse.com> References: <20130531184616.GD11399@cantiga.alporthouse.com> <1370036780-13482-1-git-send-email-ben@bwidawsk.net> <1370036780-13482-2-git-send-email-ben@bwidawsk.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from fireflyinternet.com (s16502780.onlinehome-server.info [87.106.93.118]) by gabe.freedesktop.org (Postfix) with ESMTP id C9A78E5D3C for ; Fri, 31 May 2013 16:51:05 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1370036780-13482-2-git-send-email-ben@bwidawsk.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Ben Widawsky Cc: Intel GFX List-Id: intel-gfx@lists.freedesktop.org On Fri, May 31, 2013 at 02:46:20PM -0700, Ben Widawsky wrote: > The way the stolen handling works is we take a pin on the backing pages, > but we never actually get a reference to the bo. On freeing objects > allocated with stolen memory, the final unref will end up freeing the > object with pinned pages count left. To enable an assertion to catch > bugs in this code path, this patch cleans up that remaining pin. > > Signed-off-by: Ben Widawsky That neatly explains the WARN. Not too happy about accumulating lots of backing storage specific processing into free_object, but that can be fixed up later (there is an obj->ops->release() pending). Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre