From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maarten Lankhorst Subject: Re: [PATCH 1/2] drm/i915: unpin backing storage in dmabuf_unmap Date: Wed, 07 Aug 2013 12:40:11 +0200 Message-ID: <5202240B.6070008@canonical.com> References: <1375870173-20269-1-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1375870173-20269-1-git-send-email-daniel.vetter@ffwll.ch> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: Intel Graphics Development , DRI Development List-Id: dri-devel@lists.freedesktop.org Op 07-08-13 12:09, Daniel Vetter schreef: > This fixes a WARN in i915_gem_free_object when the > obj->pages_pin_count isn't 0. > > v2: Add locking to unmap, noticed by Chris Wilson. Note that even > though we call unmap with our own dev->struct_mutex held that won't > result in an immediate deadlock since we never go through the dma_buf > interfaces for our own, reimported buffers. But it's still easy to > blow up and anger lockdep, but that's already the case with our ->map > implementation. Fixing this for real will involve per dma-buf ww mutex > locking by the callers. And lots of fun. So go with the duct-tape > approach for now. > > Cc: Chris Wilson > Reported-by: Maarten Lankhorst > Cc: Maarten Lankhorst > Tested-by: Armin K. (v1) > Signed-off-by: Daniel Vetter > Acked, this was my original patch to solve the issue. I want to note that locking struct_mutex here will break lockdep, but it's a problem in drm, not this patch. ~Maarten