From patchwork Thu Aug 8 07:10:37 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 2840797 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id D39F6BF535 for ; Thu, 8 Aug 2013 07:19:39 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id BEDAB20149 for ; Thu, 8 Aug 2013 07:19:38 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id D1DBD20145 for ; Thu, 8 Aug 2013 07:19:36 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B4534E7564 for ; Thu, 8 Aug 2013 00:19:36 -0700 (PDT) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by gabe.freedesktop.org (Postfix) with ESMTP id 66F13E7562 for ; Thu, 8 Aug 2013 00:11:02 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id d10so1255372eaj.12 for ; Thu, 08 Aug 2013 00:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=vejIfc47fjQi5k5lTjnHsg3WU1jDjXTL2Db4H2iDZJ4=; b=ks7ooTIN5Erk4suvipaosVo6nO2h8Ai31ZdGsb6CUTQ7Ig6AcJRbB5fwNsWz21xrAA BUNFOPPkMx6CounY/FQCr//cqCtGqM5noYswG4qCwj79PWJMKh8X4X+Y/ajDB8kD8GCL WNnq1Vj0KJQJxS3jR54Gp2DL5oZDnWAJH7b+U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=vejIfc47fjQi5k5lTjnHsg3WU1jDjXTL2Db4H2iDZJ4=; b=ak/yEzTaRWc8zffXNi7yQ65r0czHkSIGRlXB2BLoa79LY+1Bnd/jrceGSq9pfRb3zN cfwkkNGXfMB84qTY3l26OUOZh1QUlujltf1iu262fcbIdmnw0fXx/ForaYXJqHt0PXDD eHTLrdJ/0+J6S3S90QyYfma5+7XxSa6iiFGyY9f+N//PQFrUmvsaNLmbYu4Tn1H0V4rL Gj0M0hHeSsBiRejVJEhu5nVbfnD1dV+GPVcuajfoIIFchAlOezXeBdyzpaRYg3vOcVj9 nE4vA9jV3bpjC3o72aip7kjO55I1KWTNSIiIds2DmuZ9T4uojgKKocC7wsfV0qr3+rL5 Cpjw== X-Gm-Message-State: ALoCoQlh8XGxYpvlYKs98TQ7pE29w/yegWvYQP9u0EuJ1HbKuLiCz39adeUm9/mZkX24T3oSKO+9 X-Received: by 10.15.81.129 with SMTP id x1mr6769999eey.82.1375945861504; Thu, 08 Aug 2013 00:11:01 -0700 (PDT) Received: from aaron.ffwll.local (178-83-130-250.dynamic.hispeed.ch. [178.83.130.250]) by mx.google.com with ESMTPSA id m54sm16647369eex.2.2013.08.08.00.10.59 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 00:11:00 -0700 (PDT) From: Daniel Vetter To: Dave Airlie Subject: [PATCH 2/5] drm/i915: unpin backing storage in dmabuf_unmap Date: Thu, 8 Aug 2013 09:10:37 +0200 Message-Id: <1375945840-9784-3-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 1.8.3.2 In-Reply-To: <1375945840-9784-1-git-send-email-daniel.vetter@ffwll.ch> References: <1375945840-9784-1-git-send-email-daniel.vetter@ffwll.ch> Cc: Daniel Vetter , Intel Graphics Development , DRI Development X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org Errors-To: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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) Acked-by: Maarten Lankhorst Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/i915_gem_dmabuf.c index 63ee1a9..f7e1682 100644 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c @@ -85,9 +85,17 @@ static void i915_gem_unmap_dma_buf(struct dma_buf_attachment *attachment, struct sg_table *sg, enum dma_data_direction dir) { + struct drm_i915_gem_object *obj = attachment->dmabuf->priv; + + mutex_lock(&obj->base.dev->struct_mutex); + dma_unmap_sg(attachment->dev, sg->sgl, sg->nents, dir); sg_free_table(sg); kfree(sg); + + i915_gem_object_unpin_pages(obj); + + mutex_unlock(&obj->base.dev->struct_mutex); } static void *i915_gem_dmabuf_vmap(struct dma_buf *dma_buf)