From patchwork Sat Jul 15 09:53:28 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 9842247 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 84543602BD for ; Sat, 15 Jul 2017 09:53:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 74D1628706 for ; Sat, 15 Jul 2017 09:53:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 69E3A2872B; Sat, 15 Jul 2017 09:53:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id F31F228706 for ; Sat, 15 Jul 2017 09:53:38 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E168B6E12F; Sat, 15 Jul 2017 09:53:37 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) by gabe.freedesktop.org (Postfix) with ESMTPS id 50B006E111 for ; Sat, 15 Jul 2017 09:53:36 +0000 (UTC) Received: by mail-wm0-x244.google.com with SMTP id u23so14667125wma.2 for ; Sat, 15 Jul 2017 02:53:36 -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; bh=WQ4drGIvtQcX6wxspcJWzmrTI56cFh29KfjItZKn05s=; b=PKX7RZs22E2MOMUmqQjQ2a2rBOPOfVyc2Zx8X1yNDLNpoD7xwiVvmZOrBmoj7bt3QG 16y6oUMChdpY4t0d71F+xN8R2k+lTtM6wmIgQLFKMKpK27n4aMZPxbT9G0XuO5DisLkK ouAmKxr0C1O/Kt1poGnJC8t8no+AlEsDwumKg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=WQ4drGIvtQcX6wxspcJWzmrTI56cFh29KfjItZKn05s=; b=gNjZwbmuCOpgSNW2rlA4mLVxLYkjKoo0OO4K8/RW0C71IUFZ9WXiMGThp9U2do/KpR psrLmMGgOoPuSRB8OYBsa6b23kPOAQAGFL/Y/8TXm7mfJToYbg9BLOO8ese+xYjtWcUn WWm3sJyWntom90QkGPlzsPd2LqCRnwqiWtLHykOdjVYXctxtWU2j2ikUasluQDzK0F4X dEJCkTy62I1vITG3RkKnlUVR5WhlYoreEQEQCGtuaLERuokErofHwCoNtEmN0AnRyvGc mB9XdIVaIxomakdum0zLsnLFvGdmJnweCOCStiBA19kQQCIaQdkNOLzZrP4B+MupbjCo AJZA== X-Gm-Message-State: AIVw110xwqWF5qxIss2NYAergoVxE+zXm8jrx245yObtOs3zAuBwG3M7 87Fjd+4hmRWV5Mj9 X-Received: by 10.80.170.218 with SMTP id r26mr10044188edc.113.1500112414851; Sat, 15 Jul 2017 02:53:34 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:5640:0:960b:2678:e223:c1c6]) by smtp.gmail.com with ESMTPSA id b4sm6196189eda.34.2017.07.15.02.53.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 02:53:34 -0700 (PDT) From: Daniel Vetter To: DRI Development Date: Sat, 15 Jul 2017 11:53:28 +0200 Message-Id: <20170715095328.25671-1-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.13.2 Cc: Jiri Slaby , Peter Zijlstra , Daniel Vetter , Intel Graphics Development , Hans de Goede , Ingo Molnar , Ben Skeggs , Daniel Vetter Subject: [Intel-gfx] [PATCH] drm: Don't complain too much about struct_mutex. X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP For modern drivers the DRM core doesn't use struct_mutex at all, which means it's defacto a driver-private lock. But since we still need it for legacy drivers we can't initialize it in drivers, which means all the different instances share one lockdep key. Despite that they might be placed in totally different places in the locking hierarchy. This results in a lot of bogus lockdep splats when running stuff on systems with multiple gpus. Partially remedy the situation by only doing might_lock checks on drivers that do use struct_mutex still for gem locking. A more complete solution would be to do the mutex_init in the drm core only for legacy drivers, plus add it to each modern driver that still needs it, which would also give each its own lockdep key. Trying to do that dynamically doesn't work, because lockdep requires it's keys to be statically allocated. Cc: Hans de Goede Cc: Ben Skeggs Cc: Jiri Slaby Cc: Peter Zijlstra Cc: Ingo Molnar Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson --- drivers/gpu/drm/drm_gem.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 8dc11064253d..9663a79dd363 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -826,13 +826,15 @@ drm_gem_object_put_unlocked(struct drm_gem_object *obj) return; dev = obj->dev; - might_lock(&dev->struct_mutex); if (dev->driver->gem_free_object_unlocked) kref_put(&obj->refcount, drm_gem_object_free); - else if (kref_put_mutex(&obj->refcount, drm_gem_object_free, + else { + might_lock(&dev->struct_mutex); + if (kref_put_mutex(&obj->refcount, drm_gem_object_free, &dev->struct_mutex)) - mutex_unlock(&dev->struct_mutex); + mutex_unlock(&dev->struct_mutex); + } } EXPORT_SYMBOL(drm_gem_object_put_unlocked);