Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp5872293pxv; Thu, 29 Jul 2021 00:04:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwFjC6L/bs718MdckqMsXsUGwdZIPb7Ax5nhxGW1Uo5MNtGn5FZtmDb00Xa86Si8yt8reKp X-Received: by 2002:a05:6402:2051:: with SMTP id bc17mr4355521edb.15.1627542275193; Thu, 29 Jul 2021 00:04:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627542275; cv=none; d=google.com; s=arc-20160816; b=evui8ki3rrEN02EjAQbLVm92h4rZhTyYBLz0JY90RSB8owcFddia7uO4XOFLulnZL7 M1MHCWrbzAegPrDrZn1+PazblaXcSdEt+UcjlWnSQJhSwmp8eeJDXkfqBEUbO7K9OlU4 bzP2Jce9bCzKJRQBVHQMfIW1sLw8UsP01GVqTXYhCKV2inXTMUzeaeShoIh87Qo+jItt UbegydV0+GBvan7Inm+gTWRpXpWpUNGk+twAHe61Vp3Nzl2+tMwJpgkmm2YHohXv7ES1 snb/v+EMj3V0uI+sRWR7pGjax3+H2Hs133e2CDkJ4yhujUwridiMKjqohXBEQZvZ4dRx po8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:mail-followup-to:message-id:subject:cc:to:from:date :dkim-signature; bh=D42htALMiwE4ICut41D5vsBQfBCeDEae3tqYpmKv8jk=; b=Dj9oaC/cEipRnhQV+oDsDoiqBzh4wSUYm4B9Mgh7b3mAkwti+eJN+3dOa7J8xXiplR X8YH7ngThaNffjLbvolHQ0YFBKUsDz9CMsA+BJgtMs+CFbL0FVSHss3Q1MHDD7fG4UMB rHckRcwxoRjdpVsZHoGL9Da22C1hIGnYvrevJUgrGPy4triY+lqOFozHB2FKcYhRjf7W 1DXQTo1hb5mfUMhUCF1xW/m/CevzeVxK0KIH7EYbE3KKFGM0mdOb2bMLtKfTE2n1Bd7/ L9SREWD4dqXJkwtDd0/gruRqavAliCKs6TNbakIZHNZpKUJAYdD0vhJxyXCANDOFaH92 SSeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=OBAlPYmF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j14si2005716edq.89.2021.07.29.00.04.11; Thu, 29 Jul 2021 00:04:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=OBAlPYmF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234395AbhG2HAn (ORCPT + 99 others); Thu, 29 Jul 2021 03:00:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38278 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234347AbhG2HAl (ORCPT ); Thu, 29 Jul 2021 03:00:41 -0400 Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2816CC061765 for ; Thu, 29 Jul 2021 00:00:39 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id j2so5503065wrx.9 for ; Thu, 29 Jul 2021 00:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=D42htALMiwE4ICut41D5vsBQfBCeDEae3tqYpmKv8jk=; b=OBAlPYmFEMjLIsQidQskf+lnTNHx3ViYTxgqKf4O8loi2k8YlK8JK+7lqEWNj9D4Zs O3x76HK/w4TARBfEoxJg2AmDqouGm0u8e8Ku8kv5Hvn3ObYAuDRJ9gr69zqlVTFsA8V8 BMRfvga/i5W6OVagzBgzYq+FLZYXeor9ILVh0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=D42htALMiwE4ICut41D5vsBQfBCeDEae3tqYpmKv8jk=; b=BAQXBBQxaneG7wNppYm0ineGFiDEs//pqdKnPcGD/H273CT4BzB+GlJcl3EhVBfQQk JAxzIJhLA4fkRI33ZV5Q5dINcxKCv5GSpv5FzAKzm0suLCjGgXRgArTeiOrCnHOCaqWh L0eZ5RZhNoKUxzINUcQ9IIHlo+PsKtHLhLt6WU9YNbD8kvWZBw5lcialnd10sfncLSne zabP45i+k1a9siuy9Tumbm9dALPzk9gvlYg4q0dCYC8FN5S0R/2G1414qMZonZSrapZQ yK0iG2eLKT37mh+ZzJnUsTI0j0VkAu0ZcxxMQ0YfsXLPWvNGxaxTsaxf2L3ToO65S6P0 tjqQ== X-Gm-Message-State: AOAM531GoOzb1HZqbAhQyzttAACFqNu/75NIZvk8slLhjz8LAAz5Wzm1 1Hp19wb7DDW+BxIX4XNvoHglkw== X-Received: by 2002:adf:ef4b:: with SMTP id c11mr3047231wrp.35.1627542037754; Thu, 29 Jul 2021 00:00:37 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id g138sm2707357wmg.32.2021.07.29.00.00.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jul 2021 00:00:37 -0700 (PDT) Date: Thu, 29 Jul 2021 09:00:35 +0200 From: Daniel Vetter To: Peter Zijlstra Cc: Desmond Cheong Zhi Xi , Boqun Feng , LKML , linux-graphics-maintainer@vmware.com, zackr@vmware.com, airlied@linux.ie, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, skhan@linuxfoundation.org, gregkh@linuxfoundation.org, linux-kernel-mentees@lists.linuxfoundation.org Subject: Re: [PATCH 1/3] drm: use the lookup lock in drm_is_current_master Message-ID: Mail-Followup-To: Peter Zijlstra , Desmond Cheong Zhi Xi , Boqun Feng , LKML , linux-graphics-maintainer@vmware.com, zackr@vmware.com, airlied@linux.ie, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, skhan@linuxfoundation.org, gregkh@linuxfoundation.org, linux-kernel-mentees@lists.linuxfoundation.org References: <20210722092929.244629-1-desmondcheongzx@gmail.com> <20210722092929.244629-2-desmondcheongzx@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux phenom 5.10.0-7-amd64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 27, 2021 at 04:37:22PM +0200, Peter Zijlstra wrote: > On Thu, Jul 22, 2021 at 12:38:10PM +0200, Daniel Vetter wrote: > > On Thu, Jul 22, 2021 at 05:29:27PM +0800, Desmond Cheong Zhi Xi wrote: > > > Inside drm_is_current_master, using the outer drm_device.master_mutex > > > to protect reads of drm_file.master makes the function prone to creating > > > lock hierarchy inversions. Instead, we can use the > > > drm_file.master_lookup_lock that sits at the bottom of the lock > > > hierarchy. > > > > > > Reported-by: Daniel Vetter > > > Signed-off-by: Desmond Cheong Zhi Xi > > > --- > > > drivers/gpu/drm/drm_auth.c | 9 +++++---- > > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c > > > index f00354bec3fb..9c24b8cc8e36 100644 > > > --- a/drivers/gpu/drm/drm_auth.c > > > +++ b/drivers/gpu/drm/drm_auth.c > > > @@ -63,8 +63,9 @@ > > > > > > static bool drm_is_current_master_locked(struct drm_file *fpriv) > > > { > > > - lockdep_assert_held_once(&fpriv->minor->dev->master_mutex); > > > - > > > + /* Either drm_device.master_mutex or drm_file.master_lookup_lock > > > + * should be held here. > > > + */ > > > > Disappointing that lockdep can't check or conditions for us, a > > lockdep_assert_held_either would be really neat in some cases. > > > > Adding lockdep folks, maybe they have ideas. > > #ifdef CONFIG_LOCKDEP > WARN_ON_ONCE(debug_locks && !(lockdep_is_held(&drm_device.master_mutex) || > lockdep_is_held(&drm_file.master_lookup_lock))); > #endif > > doesn't exactly roll off the tongue, but should do as you want I > suppose. > > Would something like: > > #define lockdep_assert(cond) WARN_ON_ONCE(debug_locks && !(cond)) > > Such that we can write: > > lockdep_assert(lockdep_is_held(&drm_device.master_mutex) || > lockdep_is_held(&drm_file.master_lookup_lock)); > > make it better ? Yeah I think that's pretty tidy and flexible. Desmond, can you pls give this a shot with Peter's patch below? -Daniel > > --- > Subject: locking/lockdep: Provide lockdep_assert{,_once}() helpers > > Extract lockdep_assert{,_once}() helpers to more easily write composite > assertions like, for example: > > lockdep_assert(lockdep_is_held(&drm_device.master_mutex) || > lockdep_is_held(&drm_file.master_lookup_lock)); > > Signed-off-by: Peter Zijlstra (Intel) > --- > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h > index 5cf387813754..0da67341c1fb 100644 > --- a/include/linux/lockdep.h > +++ b/include/linux/lockdep.h > @@ -306,31 +306,29 @@ extern void lock_unpin_lock(struct lockdep_map *lock, struct pin_cookie); > > #define lockdep_depth(tsk) (debug_locks ? (tsk)->lockdep_depth : 0) > > -#define lockdep_assert_held(l) do { \ > - WARN_ON(debug_locks && \ > - lockdep_is_held(l) == LOCK_STATE_NOT_HELD); \ > - } while (0) > +#define lockdep_assert(cond) \ > + do { WARN_ON(debug_locks && !(cond)); } while (0) > > -#define lockdep_assert_not_held(l) do { \ > - WARN_ON(debug_locks && \ > - lockdep_is_held(l) == LOCK_STATE_HELD); \ > - } while (0) > +#define lockdep_assert_once(cond) \ > + do { WARN_ON_ONCE(debug_locks && !(cond)); } while (0) > > -#define lockdep_assert_held_write(l) do { \ > - WARN_ON(debug_locks && !lockdep_is_held_type(l, 0)); \ > - } while (0) > +#define lockdep_assert_held(l) \ > + lockdep_assert(lockdep_is_held(l) != LOCK_STAT_NOT_HELD) > > -#define lockdep_assert_held_read(l) do { \ > - WARN_ON(debug_locks && !lockdep_is_held_type(l, 1)); \ > - } while (0) > +#define lockdep_assert_not_held(l) \ > + lockdep_assert(lockdep_is_held(l) != LOCK_STATE_HELD) > > -#define lockdep_assert_held_once(l) do { \ > - WARN_ON_ONCE(debug_locks && !lockdep_is_held(l)); \ > - } while (0) > +#define lockdep_assert_held_write(l) \ > + lockdep_assert(lockdep_is_held_type(l, 0)) > > -#define lockdep_assert_none_held_once() do { \ > - WARN_ON_ONCE(debug_locks && current->lockdep_depth); \ > - } while (0) > +#define lockdep_assert_held_read(l) \ > + lockdep_assert(lockdep_is_held_type(l, 1)) > + > +#define lockdep_assert_held_once(l) \ > + lockdep_assert_once(lockdep_is_held(l) != LOCK_STAT_NOT_HELD) > + > +#define lockdep_assert_none_held_once() \ > + lockdep_assert_once(!current->lockdep_depth) > > #define lockdep_recursing(tsk) ((tsk)->lockdep_recursion) > > @@ -407,6 +405,9 @@ extern int lock_is_held(const void *); > extern int lockdep_is_held(const void *); > #define lockdep_is_held_type(l, r) (1) > > +#define lockdep_assert(c) do { } while (0) > +#define lockdep_assert_once(c) do { } while (0) > + > #define lockdep_assert_held(l) do { (void)(l); } while (0) > #define lockdep_assert_not_held(l) do { (void)(l); } while (0) > #define lockdep_assert_held_write(l) do { (void)(l); } while (0) > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch