From patchwork Tue Nov 19 21:08:42 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 11252675 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 3E913930 for ; Tue, 19 Nov 2019 21:09:06 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 27AEB22311 for ; Tue, 19 Nov 2019 21:09:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 27AEB22311 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5748D6E8EB; Tue, 19 Nov 2019 21:08:59 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) by gabe.freedesktop.org (Postfix) with ESMTPS id 302706E409 for ; Tue, 19 Nov 2019 21:08:53 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id q70so4781460wme.1 for ; Tue, 19 Nov 2019 13:08:53 -0800 (PST) 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=Y5re2skVyJQ7FpMrRORrHIC5wQLtJ6SKEG1wsk2e/c8=; b=SVFDkLjASvyEeQ4/FWzdMnKfa4rMNq/FBQeukbVTDc5c2S5PTiCdWtNeu0pIePqi4W hrS4NHY0xObse1sVN1f9VFtkTzxtiOKm6pQtqows8DZT6gSJsXttjyEYeQRr5LAxNlK6 5+mecI22KV7k2BkVZV6XwjHNRlYiotdlrcbO0Uz1kwLHwdWHiKnWtfufkCmiCY0CfRQY pfhP0Tb/2U5zztAVPwnuRKb1BmBSX18iurZtSjc00MuksUZ/XHBuuuzt8pxHzWL8dm07 24qI8E2cPj9KIYqKWpnLMrp4zO0T7ATz5S1WSnUIarmkBJ2LQI/Le+vVbCkVv6CHqz8E brRQ== X-Gm-Message-State: APjAAAX/d716RZUQsVusdxRVnoSDybKhmJXQuMiKnmrjntGxRzdrv/aM K8+em0qaCOBPrx/V1qkiXGzjygZiQKs= X-Google-Smtp-Source: APXvYqxn4yUMFVNXmX0Xjpq+0vGRwbmPXPP6r0C+gI7qXZ1ejuLf1nVKs6zO925z06kdmayUJfilyw== X-Received: by 2002:a05:600c:2911:: with SMTP id i17mr8204593wmd.83.1574197731570; Tue, 19 Nov 2019 13:08:51 -0800 (PST) Received: from phenom.ffwll.local (212-51-149-96.fiber7.init7.net. [212.51.149.96]) by smtp.gmail.com with ESMTPSA id z14sm28005126wrl.60.2019.11.19.13.08.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Nov 2019 13:08:50 -0800 (PST) From: Daniel Vetter To: Intel Graphics Development , DRI Development Date: Tue, 19 Nov 2019 22:08:42 +0100 Message-Id: <20191119210844.16947-2-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.24.0 In-Reply-To: <20191119210844.16947-1-daniel.vetter@ffwll.ch> References: <20191119210844.16947-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 X-Mailman-Original-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-transfer-encoding; bh=Y5re2skVyJQ7FpMrRORrHIC5wQLtJ6SKEG1wsk2e/c8=; b=CtdDUX6ku/xkoV851l2hN+CPJdfXJJF7vzF85lu3Rs4abv8F6/wEHa0YUGyEZum8AD aE9GVZmVMJJqnb4QYj6A0QvtB6cqajcCVa0VZxeBlONCgKYHdIyQRzN1uuAoKONPEOZ7 sUqF8Aux8kdMpdEaWOOX1ljq52drczoeqW3Bk= Subject: [Intel-gfx] [PATCH 1/3] drm/modeset: Prime modeset lock vs dma_resv X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Daniel Vetter , Daniel Vetter , =?utf-8?q?Christian_K=C3=B6nig?= Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" It's kinda really hard to get this wrong on a driver with both display and dma_resv locking. But who ever knows, so better to make sure that really all drivers nest these the same way. For actual lock semantics the acquire context nesting doesn't matter. But to teach lockdep what's going on with ww_mutex the acquire ctx is a fake lockdep lock, hence from a lockdep pov it does matter. That's why I figured better to include it. Cc: Maarten Lankhorst Cc: Chris Wilson Cc: Christian König Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_mode_config.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c index 3b570a404933..08e6eff6a179 100644 --- a/drivers/gpu/drm/drm_mode_config.c +++ b/drivers/gpu/drm/drm_mode_config.c @@ -27,6 +27,7 @@ #include #include #include +#include #include "drm_crtc_internal.h" #include "drm_internal.h" @@ -415,6 +416,33 @@ void drm_mode_config_init(struct drm_device *dev) dev->mode_config.num_crtc = 0; dev->mode_config.num_encoder = 0; dev->mode_config.num_total_plane = 0; + + if (IS_ENABLED(CONFIG_LOCKDEP)) { + struct drm_modeset_acquire_ctx modeset_ctx; + struct ww_acquire_ctx resv_ctx; + struct dma_resv resv; + int ret; + + dma_resv_init(&resv); + + drm_modeset_acquire_init(&modeset_ctx, 0); + ret = drm_modeset_lock(&dev->mode_config.connection_mutex, + &modeset_ctx); + if (ret == -EDEADLK) + ret = drm_modeset_backoff(&modeset_ctx); + + ww_acquire_init(&resv_ctx, &reservation_ww_class); + ret = dma_resv_lock(&resv, &resv_ctx); + if (ret == -EDEADLK) + dma_resv_lock_slow(&resv, &resv_ctx); + + dma_resv_unlock(&resv); + ww_acquire_fini(&resv_ctx); + + drm_modeset_drop_locks(&modeset_ctx); + drm_modeset_acquire_fini(&modeset_ctx); + dma_resv_fini(&resv); + } } EXPORT_SYMBOL(drm_mode_config_init); From patchwork Tue Nov 19 21:08:43 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 11252665 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id B5C876C1 for ; Tue, 19 Nov 2019 21:08:57 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9F0132231C for ; Tue, 19 Nov 2019 21:08:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F0132231C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B584B6E40D; Tue, 19 Nov 2019 21:08:55 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by gabe.freedesktop.org (Postfix) with ESMTPS id 68F076E409 for ; Tue, 19 Nov 2019 21:08:54 +0000 (UTC) Received: by mail-wm1-x343.google.com with SMTP id b11so4769297wmb.5 for ; Tue, 19 Nov 2019 13:08:54 -0800 (PST) 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=2zlbs2pXUEmTBiqM5uPjmApb3LNff5iUPeL5FIOnQYk=; b=sjDpwcGytF6C1bkn+WHdIOI0EdjPNKskr1Bcr2ehNiccXRv8qfURx1BsO0wLXkvWNN x/wOb9I9CId9Hs36gHHb5WsHR+HemkTMUWxYSVWNKQex/nN0VVplb9K0WIa5/ijfJtaH DsgB4X7jNhRXHXHaCLMtwFshgpHRBTKU3c6FRJvB0EmOxNM9cZ8YHi4Vaq7VQVrWjyKB RcUfdRJf3g46t3XVEuDtrUjPnK/RMPvC/WbdNZC7XneM1Xu1yvSbxRzFv4IPLRm49K/e Lsg4xVmd1nJeGuzDbo9tkzoj4hrZR5W8W5Av1ngaGX9K22p4Kc2LjdA6tNA+D44/E6m9 KnFQ== X-Gm-Message-State: APjAAAXTWP2OVvoVa7yjholXAA9MjlhGfm2egscD+RvNf/tPirEht5D5 7HAozNus5uKOpZT1e0GmQSsMLgGD9zk= X-Google-Smtp-Source: APXvYqzxX3jOaHPiLm+PN11cjUpEZn6I77rrmK+0fYGUxMig2vga+11YIaGfPENiJrgAdlabNeLEyg== X-Received: by 2002:a1c:41c2:: with SMTP id o185mr7906751wma.34.1574197732676; Tue, 19 Nov 2019 13:08:52 -0800 (PST) Received: from phenom.ffwll.local (212-51-149-96.fiber7.init7.net. [212.51.149.96]) by smtp.gmail.com with ESMTPSA id z14sm28005126wrl.60.2019.11.19.13.08.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Nov 2019 13:08:52 -0800 (PST) From: Daniel Vetter To: Intel Graphics Development , DRI Development Date: Tue, 19 Nov 2019 22:08:43 +0100 Message-Id: <20191119210844.16947-3-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.24.0 In-Reply-To: <20191119210844.16947-1-daniel.vetter@ffwll.ch> References: <20191119210844.16947-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 X-Mailman-Original-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-transfer-encoding; bh=2zlbs2pXUEmTBiqM5uPjmApb3LNff5iUPeL5FIOnQYk=; b=ctaU3sXxMTMJ5J+YF5brTmEYkt8Lr8VGNpVjiIlvoDVnfpkFwRT2zYTiVRMmduytPY fBE0ZX1DtprGbTrac/f5b2ZXqUDRa7rNEks7+/5DUWVD/qXNDL3URNpN8k4cuLw37RxR 3aXsKrgEyTsNzdYwlxwhhHU9VVrMKAXjOp7aQ= Subject: [Intel-gfx] [PATCH 2/3] dma-resv: Also prime acquire ctx for lockdep X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rob Herring , Daniel Vetter , Russell King , =?utf-8?q?Christian_K=C3=B6ni?= =?utf-8?q?g?= , linaro-mm-sig@lists.linaro.org, Eric Anholt , Huang Rui , Ben Skeggs , Lucas Stach , Alex Deucher , Daniel Vetter , Sumit Semwal , linux-media@vger.kernel.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Semnatically it really doesn't matter where we grab the ticket. But since the ticket is a fake lockdep lock, it matters for lockdep validation purposes. This means stuff like grabbing a ticket and then doing copy_from/to_user isn't allowed anymore. This is a changed compared to the current ttm fault handler, which doesn't bother with having a full reservation. Since I'm looking into fixing the TODO entry in ttm_mem_evict_wait_busy() I think that'll have to change sooner or later anyway, better get started. A bit more context on why I'm looking into this: For backwards compat with existing i915 gem code I think we'll have to do full slowpath locking in the i915 equivalent of the eviction code. And with dynamic dma-buf that will leak across drivers, so another thing we need to standardize and make sure it's done the same way everyway. Unfortunately this means another full audit of all drivers: - gem helpers: acquire_init is done right before taking locks, so no problem. Same for acquire_fini and unlocking, which means nothing that's not already covered by the dma_resv_lock rules will be caught with this extension here to the acquire_ctx. - etnaviv: An absolute massive amount of code is run between the acquire_init and the first lock acquisition in submit_lock_objects. But nothing that would touch user memory and could cause a fault. Furthermore nothing that uses the ticket, so even if I missed something, it would be easy to fix by pushing the acquire_init right before the first use. Similar on the unlock/acquire_fini side. - i915: Right now (and this will likely change a lot rsn) the acquire ctx and actual locks are right next to each another. No problem. - msm has a problem: submit_create calls acquire_init, but then submit_lookup_objects() has a bunch of copy_from_user to do the object lookups. That's the only thing before submit_lock_objects call dma_resv_lock(). Despite all the copypasta to etnaviv, etnaviv does not have this issue since it copies all the userspace structs earlier. submit_cleanup does not have any such issues. With the prep patch to pull out the acquire_ctx and reorder it msm is going to be safe too. - nouveau: acquire_init is right next to ttm_bo_reserve, so all good. Similar on the acquire_fini/ttm_bo_unreserve side. - ttm execbuf utils: acquire context and locking are even in the same functions here (one function to reserve everything, the other to unreserve), so all good. - vc4: Another case where acquire context and locking are handled in the same functions (one function to lock everything, the other to unlock). Cc: Maarten Lankhorst Cc: Chris Wilson Cc: Christian König Cc: Sumit Semwal Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: Huang Rui Cc: Eric Anholt Cc: Ben Skeggs Cc: Alex Deucher Cc: Rob Herring Cc: Lucas Stach Cc: Russell King Cc: Christian Gmeiner Cc: Rob Clark Cc: Sean Paul Signed-off-by: Daniel Vetter Acked-by: Christian König Reviewed-by: Maarten Lankhorst --- drivers/dma-buf/dma-resv.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index d3c760e19991..079e38fde33a 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -100,7 +100,9 @@ static void dma_resv_list_free(struct dma_resv_list *list) static void __init dma_resv_lockdep(void) { struct mm_struct *mm = mm_alloc(); + struct ww_acquire_ctx ctx; struct dma_resv obj; + int ret; if (!mm) return; @@ -108,10 +110,14 @@ static void __init dma_resv_lockdep(void) dma_resv_init(&obj); down_read(&mm->mmap_sem); - ww_mutex_lock(&obj.lock, NULL); + ww_acquire_init(&ctx, &reservation_ww_class); + ret = dma_resv_lock(&obj, &ctx); + if (ret == -EDEADLK) + dma_resv_lock_slow(&obj, &ctx); fs_reclaim_acquire(GFP_KERNEL); fs_reclaim_release(GFP_KERNEL); ww_mutex_unlock(&obj.lock); + ww_acquire_fini(&ctx); up_read(&mm->mmap_sem); mmput(mm); From patchwork Tue Nov 19 21:08:44 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 11252673 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 6DDAC930 for ; Tue, 19 Nov 2019 21:09:05 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 56D1822311 for ; Tue, 19 Nov 2019 21:09:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 56D1822311 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C12EC6E409; Tue, 19 Nov 2019 21:08:58 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0E5406E3F2 for ; Tue, 19 Nov 2019 21:08:56 +0000 (UTC) Received: by mail-wm1-x341.google.com with SMTP id c22so5492675wmd.1 for ; Tue, 19 Nov 2019 13:08:55 -0800 (PST) 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=/J7G3D2ebt6Z0HB4QG8yK+4PVkYn3CZE5ldyfHzxSrE=; b=WaD1qX8K5gRqd4HJEWYn1C9WqhCZDh7C/tCf6CgTY8bmFtFKaO2+yXAWriEOlPq+oe c/u9tWMOdjkHMEvo0R7c4qaM4evS5GmnZdMohSOjmLPVl9iKgSCvSdQdOkNnc1/XrG3x EIyba2YNVfCwwgtHJpc7cHpOILDbrK3uoLaPH/ozzqugElOqI+Y8itRaK6fuXJl8/15N A+9m679tVCkyOrxb/Dy23QH4B2TEY6DBR15BL+VU2wg3GzrEe5jM7mdXhtv/51SesFTR 7oyiWh9VkB/BCS4zb6VWTchmIbz+qCJvs02sMdxP526mNDgXFHUTbsZ5i5OlundjdxpL dICg== X-Gm-Message-State: APjAAAWjt4pQV3i/a3APs0GFu0t+0kP2w0A82DgD8nKg30epJBBk5uLn DLP69FAX9VRDb14+LicpL/6KIZ7Vqc8= X-Google-Smtp-Source: APXvYqweGr5lRb2H3jBAb7BO6vyXvuEU0Xn9y82lr1/l6PpO5IamxURKkygb4S/V5DyM3yZ+YUBQ7Q== X-Received: by 2002:a1c:9a81:: with SMTP id c123mr8080941wme.118.1574197733780; Tue, 19 Nov 2019 13:08:53 -0800 (PST) Received: from phenom.ffwll.local (212-51-149-96.fiber7.init7.net. [212.51.149.96]) by smtp.gmail.com with ESMTPSA id z14sm28005126wrl.60.2019.11.19.13.08.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Nov 2019 13:08:53 -0800 (PST) From: Daniel Vetter To: Intel Graphics Development , DRI Development Date: Tue, 19 Nov 2019 22:08:44 +0100 Message-Id: <20191119210844.16947-4-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.24.0 In-Reply-To: <20191119210844.16947-1-daniel.vetter@ffwll.ch> References: <20191119210844.16947-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 X-Mailman-Original-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-transfer-encoding; bh=/J7G3D2ebt6Z0HB4QG8yK+4PVkYn3CZE5ldyfHzxSrE=; b=Y/D3zFMQVqiSBfqH6DZ+/jejFtdbuHL69Yvo58kYvUYGswh2OtzunEL51V44+jnRNa ri1kIAI1ZNJN/CtNFGIo+A400H2rA2nL/IEVUKaLYCYC1t/ulVTa46bNV8lnrM52+bJh 1LyG44aDuM6YxyD6IdzCvZtz5DTf0tod3Ew+I= Subject: [Intel-gfx] [PATCH 3/3] drm/msm: Don't init ww_mutec acquire ctx before needed X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Daniel Vetter , linux-arm-msm@vger.kernel.org, Daniel Vetter , freedreno@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" For locking semantics it really doesn't matter when we grab the ticket. But for lockdep validation it does: the acquire ctx is a fake lockdep. Since other drivers might want to do a full multi-lock dance in their fault-handler, not just lock a single dma_resv. Therefore we must init the acquire_ctx only after we've done all the copy_*_user or anything else that might trigger a pagefault. For msm this means we need to move it past submit_lookup_objects. Aside: Why is msm still using struct_mutex, it seems to be using dma_resv_lock for general buffer state protection? Signed-off-by: Daniel Vetter Cc: Rob Clark Cc: Sean Paul Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org --- drivers/gpu/drm/msm/msm_gem_submit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c b/drivers/gpu/drm/msm/msm_gem_submit.c index fb1fdd7fa3ef..126b2f62bfe7 100644 --- a/drivers/gpu/drm/msm/msm_gem_submit.c +++ b/drivers/gpu/drm/msm/msm_gem_submit.c @@ -54,7 +54,6 @@ static struct msm_gem_submit *submit_create(struct drm_device *dev, INIT_LIST_HEAD(&submit->node); INIT_LIST_HEAD(&submit->bo_list); - ww_acquire_init(&submit->ticket, &reservation_ww_class); return submit; } @@ -489,6 +488,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data, if (ret) goto out; + ww_acquire_init(&submit->ticket, &reservation_ww_class); ret = submit_lock_objects(submit); if (ret) goto out;