Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp424456pxv; Thu, 22 Jul 2021 03:40:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzUaiIc3QK7S6/Jld8NJswARI2/yXamrcoYlaTw3ydrj7PYTnLa9RUXUXIYSrX+ntnPdgK+ X-Received: by 2002:a05:6402:193:: with SMTP id r19mr54475460edv.104.1626950419806; Thu, 22 Jul 2021 03:40:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626950419; cv=none; d=google.com; s=arc-20160816; b=mEonM8SxTWVWwQxrMDl4D7h/x/xr7LYMyhfIYZpHPn5qiMWYn+gnMXX2ECdlMy8ceY U152BXMyrComb1vddgX814YR3M4w6MDyhg31RgtEJKQNNVG3h56oP1DmBQ5C2ieUEVW4 IoRWKo8+YJ0Faf+8cBVYrpOATiSCM5W+UT75RFXwou3ToOQbZjkbnja7s8/dbvauS1D6 Vvf8QkVPtrhf0PbMfTWtWgWNx73/uIzcVMxfLpGYcvkWXKXsQ8l8DOApzaSY+6dMPaIz IL1aH39LQHUrB1gwh6OJ2l9oqrkqpICLlB+v5NvSp11VpQCO9M8Ba4YmRTUv24Jd4+xC B8CA== 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=Wstdp1MW7vJbJhg9S6cQf30gHHvyvOesRSnlOhoSLio=; b=Pd5jGQvK4Jyf85n8+75DbjJ1aK+4+BWU/0q496NEgf2m6ZX5v9Sc4iU5cO1CldXnjM uZOaGB5OhY4HjQYO8nWTSP6Fps0KQTyJO7GkvH2s6gp6fo3RRzopuDdikKTr60Z3Egey oxP3K0T/SaACFbchfJCaB76hGwSdZRWzJuutvv0DCl9paaHzoOsIAmt8Zcoy7JgM4mSy LRiqSDA65TCXNBB4ZTeVLWAGw5xqWhR0k7SK/bTn/9RnmznxhvWNl4GcZDKVnbCV8ZXj 6hUULTBshF3lWaGujNuXgVJtyX9N21KPhQ62cG9uJ41kEVv4aXu5hocgbrkFCuT5PTVq /IUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=h+h448QZ; 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 d5si30679623ejw.652.2021.07.22.03.39.56; Thu, 22 Jul 2021 03:40:19 -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=h+h448QZ; 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 S231528AbhGVJ5l (ORCPT + 99 others); Thu, 22 Jul 2021 05:57:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231325AbhGVJ5k (ORCPT ); Thu, 22 Jul 2021 05:57:40 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0BC6C061575 for ; Thu, 22 Jul 2021 03:38:13 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id c17so7628511ejk.13 for ; Thu, 22 Jul 2021 03:38:13 -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=Wstdp1MW7vJbJhg9S6cQf30gHHvyvOesRSnlOhoSLio=; b=h+h448QZAeHgdzElhjIT7EVFpu2g3yncCXFAsqDRIlSE3VCkeb8XYv1XLXU30ldtly DYH4gNzgye3p6+lFgsRyqYCHq9GBYVe783jE5nqDtXJZNpJjsMpO2Vwi7vCWnNl0RJkk S3ujNtCviEkax03zXYTgYFkpLx5jQLmG/h14o= 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=Wstdp1MW7vJbJhg9S6cQf30gHHvyvOesRSnlOhoSLio=; b=oUm97CHyN7Oc800HXWXdFZhYaCb3LogC2D8sXQJcqqH8LwzVzDIkptRcC9Jdo+soQU nt47I/P+wFcC32UPHwaGpgxg3K4kD4NRmDJyJJcWgKWuwCqXZ8fYE6GLKa7UG0OowJ2h rNaddD7oRhq0U7Ubggh0avVpsiICYzmUP6XaeexLcsjkLnLlt7di8Jd8JOBPLeYCNHm1 5HRUlrLXU2Nm0OGlrpJHNz6xswRoZ3svydrXBbudsSuSR4KdafJZVAevwtz+VMB0tQRo ab9IFK3xbQ4fvLKCp5gW0+HUWZd/6VoquvdamwdSVNmyIacZImM4fRAQezpDYGMcsBnC Sc9Q== X-Gm-Message-State: AOAM532KaNyvliGtETS0h+bHWNblbiZV4WqGx7b8DJ7YQqMHfFhve0MN FKMAVSaSCxpaF3pdf60Zy29Plg== X-Received: by 2002:a17:906:f92:: with SMTP id q18mr43617437ejj.353.1626950292593; Thu, 22 Jul 2021 03:38:12 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id cn21sm12272770edb.81.2021.07.22.03.38.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jul 2021 03:38:11 -0700 (PDT) Date: Thu, 22 Jul 2021 12:38:10 +0200 From: Daniel Vetter To: Desmond Cheong Zhi Xi , Boqun Feng , LKML , Peter Zijlstra Cc: linux-graphics-maintainer@vmware.com, zackr@vmware.com, airlied@linux.ie, daniel@ffwll.ch, maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org, skhan@linuxfoundation.org, gregkh@linuxfoundation.org, linux-kernel-mentees@lists.linuxfoundation.org, Daniel Vetter Subject: Re: [PATCH 1/3] drm: use the lookup lock in drm_is_current_master Message-ID: Mail-Followup-To: Desmond Cheong Zhi Xi , Boqun Feng , LKML , Peter Zijlstra , 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: <20210722092929.244629-2-desmondcheongzx@gmail.com> X-Operating-System: Linux phenom 5.10.0-7-amd64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. On the patch: Reviewed-by: Daniel Vetter > return fpriv->is_master && drm_lease_owner(fpriv->master) == fpriv->minor->dev->master; > } > > @@ -82,9 +83,9 @@ bool drm_is_current_master(struct drm_file *fpriv) > { > bool ret; > > - mutex_lock(&fpriv->minor->dev->master_mutex); > + spin_lock(&fpriv->master_lookup_lock); > ret = drm_is_current_master_locked(fpriv); > - mutex_unlock(&fpriv->minor->dev->master_mutex); > + spin_unlock(&fpriv->master_lookup_lock); > > return ret; > } > -- > 2.25.1 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch