From patchwork Tue Aug 20 08:19:51 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 11103295 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 BD95314F7 for ; Tue, 20 Aug 2019 08:20:15 +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 A584523A1D for ; Tue, 20 Aug 2019 08:20:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A584523A1D 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 EAC816E82C; Tue, 20 Aug 2019 08:20:03 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by gabe.freedesktop.org (Postfix) with ESMTPS id 092DD6E827 for ; Tue, 20 Aug 2019 08:20:01 +0000 (UTC) Received: by mail-ed1-x544.google.com with SMTP id t50so2379542edd.2 for ; Tue, 20 Aug 2019 01:20:00 -0700 (PDT) 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=P0MHbp8icd2EnfbEt8W/+7c9GESmHjcRIzzc5mREfHc=; b=inAfBuoFYXFVq68aLYbo7fP7xEXHxH8Dd4RtI9yE8YizrQ4W8PjVi6a2y7TSXmbxAN p4VbC7v0/MmPFBZog7wvDYa3OXqyMp+aN3uhPP2/nWu+iV+drE3BI+c3bm9V2C8sndTY n9bddFbGwdvno4OxrADIQKNggHdpnHHkBJ0L5CK9scIJDZjewYs4Zi5XDBcVpvK4qt48 Z4qpfheemfcX8OgTEvuk1AkJE5YYUPnNtZK6JEXCJCiah+3jH2QAV+/IOg3iFJ3I35UI 02fiunbMh6BosrgFTSfSv03dmnoOdFveGoqYyW1ybm45r1QuxVMZndDoHRnumlTkmeFD FCmA== X-Gm-Message-State: APjAAAUVBFkMxCUMO0GU2dFKsyTHI8qYnab9dTf0s5OziSzNw1laYECP vJ8hcd7AL/nOIy9q+gCaiUUKRMSAmXgubA== X-Google-Smtp-Source: APXvYqwws+tGdhwNI/AHb6Ki0sR410Q/kQWDEPFTsVjfkvGHAhHMdqj8R+dup9TBx0dLBbst5g9vkw== X-Received: by 2002:a17:906:9b1:: with SMTP id q17mr10487760eje.224.1566289199282; Tue, 20 Aug 2019 01:19:59 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:569e:0:3106:d637:d723:e855]) by smtp.gmail.com with ESMTPSA id i4sm2467705ejs.39.2019.08.20.01.19.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Aug 2019 01:19:58 -0700 (PDT) From: Daniel Vetter To: Intel Graphics Development Date: Tue, 20 Aug 2019 10:19:51 +0200 Message-Id: <20190820081951.25053-3-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.23.0.rc1 In-Reply-To: <20190820081951.25053-1-daniel.vetter@ffwll.ch> References: <20190820081951.25053-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=P0MHbp8icd2EnfbEt8W/+7c9GESmHjcRIzzc5mREfHc=; b=ZWhyXfvekp7mtomOPeNw+gKv8PoctORQT4qK6vDORYQfVlFc1kfl2BJJV3TJHQGZCb CB0pHjKkl5vhMQORtswylUJcIGVL8oEiKsxpArAFePsSZ3hLP59vaTJNnC9fuUB3KIBn d39pjVY9A1d2vscbkTfyqP3a+l5l1lbvao8nc= Subject: [Intel-gfx] [PATCH 3/3] drm/i915: use might_lock_nested in get_pages annotation 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: Peter Zijlstra , Daniel Vetter , LKML , Ingo Molnar , Daniel Vetter , Will Deacon Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" 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 | 34 +++++++++++----------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h b/drivers/gpu/drm/i915/gem/i915_gem_object.h index a0b1fa8a3224..b3fd6aac93bc 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h @@ -233,10 +233,26 @@ 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; @@ -279,22 +295,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);