Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp5176873ybl; Wed, 22 Jan 2020 11:45:01 -0800 (PST) X-Google-Smtp-Source: APXvYqxY6wZn9ni/v43kF7MfMe0B2r+1tpZ0pnEQZ0GE7PUfybwZ/np1+Hjn4BPeIj336frjBCaD X-Received: by 2002:aca:c74e:: with SMTP id x75mr8266031oif.140.1579722301786; Wed, 22 Jan 2020 11:45:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579722301; cv=none; d=google.com; s=arc-20160816; b=wCarW9zeyeHQZaz2VWxI4N4I6pzk7GN0UOzRUe2JKAAYuYPfDtYdvc0aWKuNEjLj6p fh4D8Q62JJGXkmMuLhrfQ/pSzEY9M+Miz2o2DmOM2rtmGe//I9bGCL9APNrEDk3d2LtN tcCfzGDq6qhT/LWt+WCSC3zuvrfOw7udPecRtYPcaMooR3RlWfws5ZBwx4Gx/JCgfEl8 AlgAoWLuPlI0iOOv4r9L4vQZ2LyfGeGLfVEECmLY0RujcSJWQJHdmaNEf518dprOJWt2 Wks54BBGdiZATBwmT1VIMSaty/ag1QqUHSymqCmyUB6FCbdENeSLyvDYb5BfXhraEqCx 1jjw== 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 :message-id:date:subject:cc:to:from:dkim-signature; bh=5tEuUkKDhsAj/8wgfLzijJY2JLpoVThoT94FD+ztjuA=; b=wVYaRl3+gEz5MYeq9Bdr/Fk9TRT8P1oREZDi44+360RDwjDr4vibbCB4LqxiqVug3F lCzrbx5JyM+VLNoTPBuQ9PGbxFNXLRhjV3x9Za4S6ToplPkNU3UbyJ6iLJnDHq6HmVp2 wnB3OLwcp67LXs8u4M2vZ7cEUxafM0HzQ+ERuIA4pfWDkDpKAtVL0MH5jlYmedCX0i/4 woRMjRa0yCtWTLszwLPLDiFQv51Icnr8oVAN90rFvgqs5hMhW4cwbgf8KTkDEx1qFn2i rZtUmBiOrGIv605F115dGZ71tnOhpjbZVAhiFgDZ5yK9Gu++vnB57nWGr1tEM43UlkO+ HSAg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=A+p7OrQu; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t4si22850415otc.160.2020.01.22.11.44.49; Wed, 22 Jan 2020 11:45:01 -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=@redhat.com header.s=mimecast20190719 header.b=A+p7OrQu; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728928AbgAVTnn (ORCPT + 99 others); Wed, 22 Jan 2020 14:43:43 -0500 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:47775 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725827AbgAVTnn (ORCPT ); Wed, 22 Jan 2020 14:43:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1579722222; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=5tEuUkKDhsAj/8wgfLzijJY2JLpoVThoT94FD+ztjuA=; b=A+p7OrQuEDOIxnUhG2PVzrTcN7HejjrFr2bfUKM19ByTXP9QZQK4tmsHRKcpL6Xq6TkKg2 URS99DxuU7hlb/NedvG5q8hZBARH/34XPPTxcNL34/yJhM1jNRh1hsK6H/652+aHOgxsto bS+OjOs7H0HNx5olP/fnAzayGRdVXZo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-149-nKyCzFggNiS1Ck3kiyDaKg-1; Wed, 22 Jan 2020 14:43:38 -0500 X-MC-Unique: nKyCzFggNiS1Ck3kiyDaKg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C9547803776; Wed, 22 Jan 2020 19:43:35 +0000 (UTC) Received: from malachite.bss.redhat.com (dhcp-10-20-1-90.bss.redhat.com [10.20.1.90]) by smtp.corp.redhat.com (Postfix) with ESMTP id BB5C219C5B; Wed, 22 Jan 2020 19:43:31 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org Cc: Sean Paul , Wayne Lin , =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Maarten Lankhorst , Maxime Ripard , David Airlie , Daniel Vetter , linux-kernel@vger.kernel.org Subject: [PATCH v2 1/2] drm/dp_mst: Fix clearing payload state on topology disable Date: Wed, 22 Jan 2020 14:43:20 -0500 Message-Id: <20200122194321.14953-1-lyude@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Changes since v1: * Use sizeof(mgr->payloads[0])/sizeof(mgr->proposed_vcpis[0]) instead - vsyrjala Cc: Sean Paul Cc: Wayne Lin Cc: Ville Syrj=C3=A4l=C3=A4 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 3649e82b963d..23cf46bfef74 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -3501,6 +3501,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_m= st_topology_mgr *mgr, bool ms int ret =3D 0; struct drm_dp_mst_branch *mstb =3D NULL; =20 + mutex_lock(&mgr->payload_lock); mutex_lock(&mgr->lock); if (mst_state =3D=3D mgr->mst_state) goto out_unlock; @@ -3559,7 +3560,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 =3D 0; - memset(mgr->payloads, 0, mgr->max_payloads * sizeof(struct drm_dp_payl= oad)); + memset(mgr->payloads, 0, + mgr->max_payloads * sizeof(mgr->payloads[0])); + memset(mgr->proposed_vcpis, 0, + mgr->max_payloads * sizeof(mgr->proposed_vcpis[0])); mgr->payload_mask =3D 0; set_bit(0, &mgr->payload_mask); mgr->vcpi_mask =3D 0; @@ -3568,6 +3572,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_m= st_topology_mgr *mgr, bool ms =20 out_unlock: mutex_unlock(&mgr->lock); + mutex_unlock(&mgr->payload_lock); if (mstb) drm_dp_mst_topology_put_mstb(mstb); return ret; --=20 2.24.1