From patchwork Fri Feb 14 13:06:05 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 3652571 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 1E6E59F382 for ; Fri, 14 Feb 2014 13:06:31 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 36D5F20222 for ; Fri, 14 Feb 2014 13:06:30 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 5E96D2021E for ; Fri, 14 Feb 2014 13:06:29 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1FA34FB498; Fri, 14 Feb 2014 05:06:28 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by gabe.freedesktop.org (Postfix) with ESMTP id 28F65FB498 for ; Fri, 14 Feb 2014 05:06:25 -0800 (PST) Received: by mail-ea0-f169.google.com with SMTP id h10so5824118eak.14 for ; Fri, 14 Feb 2014 05:06:24 -0800 (PST) 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 :mime-version:content-type:content-transfer-encoding; bh=Kk0vBmSgtD4DNskoBzNnWLHcsbong49d7Zu+XK1VGzs=; b=EF/yDLAjVH/ox7dCkeFjUXJGpeQRR+zxHwKi5o377UaKiszhNwhzUD3LEvgMs2Ar9I Td2RtYFiSuBRXqQXzy3quXzr6LdbCK1bkJOpRBcIQQc38gCW8kF6tfFNIfPBbge/bv9K tD1dc1BVFVFJ434MXHw+6FtfaXZytPEw0GN24= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=Kk0vBmSgtD4DNskoBzNnWLHcsbong49d7Zu+XK1VGzs=; b=izSiL8XUI4Y0bos6RsB4O+tVYXCctKMBduyfFN5N+DtBdcmN1BakmUAe7OLRn2CAcn p7mD2lGEQCojJmqIZEed2UKnGDQERCSREyiiXuv2hPw0GzC6tRk0XOBG/EHJPM/ISzlQ UyqmVrzJQzGroe/dglW1E2jQ15CBacobSmCdPoUODYPKrgAzbqmadcKo4ewALx2A3VQp n+mJDL8I8bP89OvRmIuHLD8R/jT5hnKdzYW/QYdvtv3t+AjMZWkloBczqaghJCOhr724 9R0eQMFAp45OWZX1uvvzqj1FxUKNTsCze1TzN3uGDP1SyjNYtwg02tBd7T3e2e/WvRUI H1AQ== X-Gm-Message-State: ALoCoQlE0B8f2BLHp7j16CG3MVLMlIlxe3s1IJqrZ6cStBJAAPZNqYgEaISs4BRf4qv2cMNnH+JO X-Received: by 10.14.22.5 with SMTP id s5mr2073512ees.85.1392383184422; Fri, 14 Feb 2014 05:06:24 -0800 (PST) Received: from phenom.ffwll.local (84-73-67-144.dclient.hispeed.ch. [84.73.67.144]) by mx.google.com with ESMTPSA id j41sm19611083eeg.10.2014.02.14.05.06.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 14 Feb 2014 05:06:23 -0800 (PST) From: Daniel Vetter To: Intel Graphics Development Date: Fri, 14 Feb 2014 14:06:05 +0100 Message-Id: <1392383167-19948-1-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 1.8.5.2 In-Reply-To: <20140128124028.GX9454@intel.com> References: <20140128124028.GX9454@intel.com> MIME-Version: 1.0 Cc: Daniel Vetter Subject: [Intel-gfx] [PATCH 1/3] drm/i915: Don't drop pinned fences X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org X-Spam-Status: No, score=-4.7 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 Userspace can currently provoke this when e.g. trying to use a pinned scanout as a cursor or overlay target. Later on that might lead to some fun fence pin count mayhem. Spurred by Ville's report that something goes wrong here and originally I've thought that this might slip through the pwrite gtt fastpath. But that one checks of obj tiling, so should be ok. But one thing that _does_ blow up is the vma unbinding with more than one address space. The next patch will fix this. v2: Use a WARN_ON - Chris pointed out that we already catch all cases so userspace can't provoke this like I've originally feared. While reviewing relevant code I've noticed a pile of DRM_ERROR in the overlay&cursor code which are all triggerable by userspace. Tune them down while at it. v3: Split out the DRM_ERROR->DRM_DEBUG_KMS change into a separate patch, as requested by Chris. Cc: Chris Wilson Cc: Ville Syrjälä Tested-by: Ville Syrjälä Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 3618bb0cda0a..675ad96a43e1 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3010,6 +3010,9 @@ i915_gem_object_put_fence(struct drm_i915_gem_object *obj) fence = &dev_priv->fence_regs[obj->fence_reg]; + if (WARN_ON(fence->pin_count)) + return -EBUSY; + i915_gem_object_fence_lost(obj); i915_gem_object_update_fence(obj, fence, false);