Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp4219022ybx; Mon, 4 Nov 2019 09:39:03 -0800 (PST) X-Google-Smtp-Source: APXvYqyur+Ppj2uwjXiDQp2tZJtajFGTOrJ2GolVXYAE3rIcltHtv36i8LF8Fk0Dy215x3gPDjTF X-Received: by 2002:aa7:dcc4:: with SMTP id w4mr20911381edu.161.1572889143020; Mon, 04 Nov 2019 09:39:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572889143; cv=none; d=google.com; s=arc-20160816; b=fuQNB59NkkDfWJU1h5w8CSCeHrGhAjcZ2XTUDISJVwzm74f4yy6gznnsDJBiUiNvba RCI31SuNXTIZsvshyyF8PnvI9LuUJXPwCUICd5f8xOX1OO3ZJ8pX3n7BryfuPZP1X7OD u9LDLX5ScL0Ju3qc0qaLx6UB6R7W0t0jWPt2xTBrH+vS66QCWOgRn+AXz01mzTWupqvY GEp8YGd2wq8lJ6bLp2rsRBz3YIdmFYUq3El1TOI2JtyPoF6QPT5tASPAa7GjKTX9TBW4 qcz8tNNGw4QryzXFEtQ0E3irn9oCwyCgnaKaReQWo90EGgYnvm9c7QvtV3chU6hhXl55 esUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=PXKWmt04LLOdOQwT4J7BpfWO3zbtkR+P8tnC3gpeEXQ=; b=Cq885Rjc6dRXg8I4/a74tNqw6PSAVFafEqD9wrDen1N/55H98K/cTH8nhNY9/eGMrX 76BCLN3aLQj0OalachvfrZrC2K/VLTbGhOZSV5khxNkWX8RiYqnHv4oKWoeDapiInxXm jxykRwe+Ctil6ksSW3Tigp6Z/1BhmzFRRk8O4iQX3xg9CDx/BO9aUZA2Ylzt6Nu9ZNQv SfECKnRXttgEK3clJVh1hAWx5ub8QaHOqrMYHk/pAozYelu1rsx8lI36wx4eu40M0vq4 8QflDQLFVnfVzGUhiXQMrMVvQFKsiJwkAhSjWjPazhGiys8AUvhoIB6F18ARxJUrhz+X s+Rg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=VAyQzygl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p24si11726202eju.309.2019.11.04.09.38.39; Mon, 04 Nov 2019 09:39:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=VAyQzygl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729466AbfKDRhg (ORCPT + 99 others); Mon, 4 Nov 2019 12:37:36 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:50477 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728898AbfKDRhf (ORCPT ); Mon, 4 Nov 2019 12:37:35 -0500 Received: by mail-wm1-f68.google.com with SMTP id 11so17674682wmk.0 for ; Mon, 04 Nov 2019 09:37:34 -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-transfer-encoding; bh=PXKWmt04LLOdOQwT4J7BpfWO3zbtkR+P8tnC3gpeEXQ=; b=VAyQzyglRqNMJ3a4V+Jk2zst6aCR675sfvIjYWZoY/TUikK/EnbUf83SZsY6hQMvZ/ qpqrMTLp8w0fMoHxqmLb1x9cV4Jrfhnir+g7hTsKlxb8muPuiiTG+25XLfQkayp2UfU3 uqK791FxcspFJz55XB6wK9tl9Y/kCkD4f7HQs= 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=PXKWmt04LLOdOQwT4J7BpfWO3zbtkR+P8tnC3gpeEXQ=; b=OCsgoXMvq6nsiC5lO6nIWylPT0Z43TjXXt+ImMTLPtARXrTubabtyL+JWI7VK9gAtF BPG3TfCUU9ez2OkBAKCumEoSccKQxhW20Jd9BdvtEvWMBFNFdMBQRDskt1gY4et6bdQ/ KA3cbRlX6Rkb3PNNjrevlPUovMeRLC65AQdrSR5K7u2yUNRAknOkxEpRbQ1WcqItx1YR E+j5xrOj82npq8Z3UQKZmWJGSS+yGz4F248c9ONuYJyyoGU4MUagXU2cDuTPNy9fp/HZ N5c6QS3qfudpSWoa2kBf+CkOiLs2VAF5gzN5UydaB8/Y1xhwldJ7QIaJRQ2TnAIChHv2 h7fg== X-Gm-Message-State: APjAAAUH0ixoTdFQQOcIwTFuMqpf3tzcCBcytU14xw94oOBa7r8K7GVe /7dhSBX2G8oqD2zKcMA8bFAbsQ== X-Received: by 2002:a05:600c:21c9:: with SMTP id x9mr252564wmj.54.1572889053413; Mon, 04 Nov 2019 09:37:33 -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 l22sm32408863wrb.45.2019.11.04.09.37.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Nov 2019 09:37:32 -0800 (PST) From: Daniel Vetter To: Intel Graphics Development Cc: Daniel Vetter , Daniel Vetter , Peter Zijlstra , Ingo Molnar , Will Deacon , linux-kernel@vger.kernel.org Subject: [PATCH 3/3] drm/i915: use might_lock_nested in get_pages annotation Date: Mon, 4 Nov 2019 18:37:20 +0100 Message-Id: <20191104173720.2696-3-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.24.0.rc2 In-Reply-To: <20191104173720.2696-1-daniel.vetter@ffwll.ch> References: <20191104173720.2696-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org So strictly speaking the existing annotation is also ok, because we have a chain of obj->mm.lock#I915_MM_GET_PAGES -> fs_reclaim -> obj->mm.lock (the shrinker cannot get at an object while we're in get_pages, hence this is safe). But it's confusing, so try to take the right subclass of the lock. This does a bit reduce our lockdep based checking, but then it's also less fragile, in case we ever change the nesting around. Signed-off-by: Daniel Vetter Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Will Deacon Cc: linux-kernel@vger.kernel.org --- drivers/gpu/drm/i915/gem/i915_gem_object.h | 36 +++++++++++----------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h index edaf7126a84d..e5750d506cc9 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h @@ -271,10 +271,27 @@ void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj, int ____i915_gem_object_get_pages(struct drm_i915_gem_object *obj); int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj); +enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */ + I915_MM_NORMAL = 0, + /* + * Only used by struct_mutex, when called "recursively" from + * direct-reclaim-esque. Safe because there is only every one + * struct_mutex in the entire system. + */ + I915_MM_SHRINKER = 1, + /* + * Used for obj->mm.lock when allocating pages. Safe because the object + * isn't yet on any LRU, and therefore the shrinker can't deadlock on + * it. As soon as the object has pages, obj->mm.lock nests within + * fs_reclaim. + */ + I915_MM_GET_PAGES = 1, +}; + static inline int __must_check i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) { - might_lock(&obj->mm.lock); + might_lock_nested(&obj->mm.lock, I915_MM_GET_PAGES); if (atomic_inc_not_zero(&obj->mm.pages_pin_count)) return 0; @@ -317,23 +334,6 @@ i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj) __i915_gem_object_unpin_pages(obj); } -enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock/struct_mutex */ - I915_MM_NORMAL = 0, - /* - * Only used by struct_mutex, when called "recursively" from - * direct-reclaim-esque. Safe because there is only every one - * struct_mutex in the entire system. - */ - I915_MM_SHRINKER = 1, - /* - * Used for obj->mm.lock when allocating pages. Safe because the object - * isn't yet on any LRU, and therefore the shrinker can't deadlock on - * it. As soon as the object has pages, obj->mm.lock nests within - * fs_reclaim. - */ - I915_MM_GET_PAGES = 1, -}; - int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj); void i915_gem_object_truncate(struct drm_i915_gem_object *obj); void i915_gem_object_writeback(struct drm_i915_gem_object *obj); -- 2.24.0.rc2