Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5124527ybl; Wed, 22 Jan 2020 10:46:00 -0800 (PST) X-Google-Smtp-Source: APXvYqy5dTlTsmRsnrPKIzda1/oalRDCKj888/DxPw835ZCo3lhF4a5Sr7YZp0u1XX30fFWHKVTm X-Received: by 2002:a9d:7696:: with SMTP id j22mr8836561otl.188.1579718760395; Wed, 22 Jan 2020 10:46:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579718760; cv=none; d=google.com; s=arc-20160816; b=DDaRjWrksORryOHuFTF8S+bPC10crNJJDuKFdOPzEYV7xkCLN7QesHn+RQA7vQcT3I cQgT9MzQwNRhgfhFFKnttQJY6eS81nSG5V0YO4uz03/DZqJaJFyBtWjYCABugfZc3Itr S1x8uaWPvvV4+HZVmDN3gRJUib0Ci2vPZPhbhfa+/A0Z0zo8o3QE4WzS0SoXHrJBQQRO PQno3HfH6+jpAbAT++xLJMqioNcGXG3KtgdsaU0baxFwzgp6omVOrVGcWEJFPj8JJag1 PDDiSrUezxzIkMEUaFEOJoDB9YUsiN7tPqX+WkGNhPRYGtZiQlw22VLhSK45ErjsHy8y fVhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=cknNLJJV0gquQlghQmmSn9aHBaE2TmLtaXhRmeAbfsM=; b=V1Upfp2opM09Ry2HePhJ/vDVlZ5ylNwgvuYh5Brc17j6yjMaaNvXUia3kPCy/jrZbZ C1JghrQIcz9wBoGTkuHkAE1tyQw7X//XlSShATx7lvSDfR1SiOZZJtt3oPBi0Tq4yiN3 N+wTJdxHJkWFqJQBslidVfpM84Cnp8TtrjCr2b9YjUzrM9l5URThFcsD3LjsDEz3I/Mn thyouo/7+tDS+GX5MwbZ3x+yuRb7iP5s0G/a6qgpvo0+7AlC/IZUebwxI63fF7kXFBOn ydGsB5GsCmdjpqQmmVs+GR2nZpgVsBWJzEsRQmSzk7dD28jEjfwCPGJWa/fNwRl8ccza Niog== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j71si21022260oib.213.2020.01.22.10.45.47; Wed, 22 Jan 2020 10:46:00 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726135AbgAVSoq (ORCPT + 99 others); Wed, 22 Jan 2020 13:44:46 -0500 Received: from mga18.intel.com ([134.134.136.126]:32600 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725924AbgAVSoq (ORCPT ); Wed, 22 Jan 2020 13:44:46 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2020 10:44:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,350,1574150400"; d="scan'208";a="284680527" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by fmsmga001.fm.intel.com with SMTP; 22 Jan 2020 10:44:42 -0800 Received: by stinkbox (sSMTP sendmail emulation); Wed, 22 Jan 2020 20:44:41 +0200 Date: Wed, 22 Jan 2020 20:44:41 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Lyude Paul Cc: dri-devel@lists.freedesktop.org, David Airlie , linux-kernel@vger.kernel.org, Wayne Lin , Sean Paul Subject: Re: [PATCH 2/2] drm/dp_mst: Fix clearing payload state on topology disable Message-ID: <20200122184441.GE13686@intel.com> References: <20200117224749.128994-1-lyude@redhat.com> <20200117224749.128994-2-lyude@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200117224749.128994-2-lyude@redhat.com> X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 17, 2020 at 05:47:49PM -0500, Lyude Paul wrote: > The issues caused by: > > 64e62bdf04ab ("drm/dp_mst: Remove VCPI while disabling topology mgr") > > Prompted me to take a closer look at how we clear the payload state in > general when disabling the topology, and it turns out there's actually > two subtle issues here. > > The first is that we're not grabbing &mgr.payload_lock when clearing the > payloads in drm_dp_mst_topology_mgr_set_mst(). Seeing as the canonical > lock order is &mgr.payload_lock -> &mgr.lock (because we always want > &mgr.lock to be the inner-most lock so topology validation always > works), this makes perfect sense. It also means that -technically- there > could be racing between someone calling > drm_dp_mst_topology_mgr_set_mst() to disable the topology, along with a > modeset occurring that's modifying the payload state at the same time. > > The second is the more obvious issue that Wayne Lin discovered, that > we're not clearing proposed_payloads when disabling the topology. > > I actually can't see any obvious places where the racing caused by the > first issue would break something, and it could be that some of our > higher-level locks already prevent this by happenstance, but better safe > then sorry. So, let's make it so that drm_dp_mst_topology_mgr_set_mst() > first grabs &mgr.payload_lock followed by &mgr.lock so that we never > race when modifying the payload state. Then, we also clear > proposed_payloads to fix the original issue of enabling a new topology > with a dirty payload state. This doesn't clear any of the drm_dp_vcpi > structures, but those are getting destroyed along with the ports anyway. > > Cc: Sean Paul > Cc: Wayne Lin > Signed-off-by: Lyude Paul > --- > drivers/gpu/drm/drm_dp_mst_topology.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c > index 89c2a7505cbd..58287f4c1baf 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -3483,6 +3483,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms > int ret = 0; > struct drm_dp_mst_branch *mstb = NULL; > > + mutex_lock(&mgr->payload_lock); > mutex_lock(&mgr->lock); > if (mst_state == mgr->mst_state) > goto out_unlock; > @@ -3541,7 +3542,10 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms > /* this can fail if the device is gone */ > drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0); > ret = 0; > - memset(mgr->payloads, 0, mgr->max_payloads * sizeof(struct drm_dp_payload)); > + memset(mgr->payloads, 0, > + mgr->max_payloads * sizeof(struct drm_dp_payload)); > + memset(mgr->proposed_vcpis, 0, > + mgr->max_payloads * sizeof(void*)); void* is an odd choice. sizeof(foo[0]) would be more future proof (for both of these). Also might be a good idea to update the docs to mention max_payloads defines the size of these arrays. > mgr->payload_mask = 0; > set_bit(0, &mgr->payload_mask); > mgr->vcpi_mask = 0; > @@ -3550,6 +3554,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms > > out_unlock: > mutex_unlock(&mgr->lock); > + mutex_unlock(&mgr->payload_lock); > if (mstb) > drm_dp_mst_topology_put_mstb(mstb); > return ret; > -- > 2.24.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrj?l? Intel