From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CC13C33CB3 for ; Tue, 28 Jan 2020 14:15:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 71A9A24681 for ; Tue, 28 Jan 2020 14:15:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580220921; bh=AWX/DuNJZVYQPXGXvnHKH8DR01lfp6OTXqq2/wK1dV0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=rVl/VWr74oZkOUtgXtURcInAtDx9/eBWn7Qj3R1HHd0mz7wMV3Ry+1d0RxGymA6Cs NmyEE5ZIxqd5vGoR6qJ/sf4Qbh+3VUEcB7q3SWGcp1axxx6aLJVEPgYxDJas/o/6z7 iiyFEChlUohDJlDgLOfRMoBihh+E+iQ1KMaQRiL0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729609AbgA1OPO (ORCPT ); Tue, 28 Jan 2020 09:15:14 -0500 Received: from mail.kernel.org ([198.145.29.99]:37770 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729799AbgA1OPN (ORCPT ); Tue, 28 Jan 2020 09:15:13 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9AE632468D; Tue, 28 Jan 2020 14:15:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580220913; bh=AWX/DuNJZVYQPXGXvnHKH8DR01lfp6OTXqq2/wK1dV0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MUxbeLInSx2Kh9LIq9P9JpNCksVBtHBTy5UGDa24tv8K6vQimdbPGez2sSFjdxgrz EFT4otV1iKkTCJsILui1a685UznloWMh3ZF1FBZH2ZA6HQfm0uaDTF/Dk3PicKG+sQ C6gm8NyQl1jS8WGZHNmJlrcGNoZ72fTmVHwWuHeM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lyude Paul , Jerry Zuo , Harry Wentland , Dave Airlie , Sean Paul , Sasha Levin Subject: [PATCH 4.9 014/271] drm/dp_mst: Skip validating ports during destruction, just ref Date: Tue, 28 Jan 2020 15:02:43 +0100 Message-Id: <20200128135853.543916293@linuxfoundation.org> X-Mailer: git-send-email 2.25.0 In-Reply-To: <20200128135852.449088278@linuxfoundation.org> References: <20200128135852.449088278@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Lyude Paul [ Upstream commit c54c7374ff44de5e609506aca7c0deae4703b6d1 ] Jerry Zuo pointed out a rather obscure hotplugging issue that it seems I accidentally introduced into DRM two years ago. Pretend we have a topology like this: |- DP-1: mst_primary |- DP-4: active display |- DP-5: disconnected |- DP-6: active hub |- DP-7: active display |- DP-8: disconnected |- DP-9: disconnected If we unplug DP-6, the topology starting at DP-7 will be destroyed but it's payloads will live on in DP-1's VCPI allocations and thus require removal. However, this removal currently fails because drm_dp_update_payload_part1() will (rightly so) try to validate the port before accessing it, fail then abort. If we keep going, eventually we run the MST hub out of bandwidth and all new allocations will start to fail (or in my case; all new displays just start flickering a ton). We could just teach drm_dp_update_payload_part1() not to drop the port ref in this case, but then we also need to teach drm_dp_destroy_payload_step1() to do the same thing, then hope no one ever adds anything to the that requires a validated port reference in drm_dp_destroy_connector_work(). Kind of sketchy. So let's go with a more clever solution: any port that drm_dp_destroy_connector_work() interacts with is guaranteed to still exist in memory until we say so. While said port might not be valid we don't really care: that's the whole reason we're destroying it in the first place! So, teach drm_dp_get_validated_port_ref() to use the all mighty current_work() function to avoid attempting to validate ports from the context of mgr->destroy_connector_work. I can't see any situation where this wouldn't be safe, and this avoids having to play whack-a-mole in the future of trying to work around port validation. Signed-off-by: Lyude Paul Fixes: 263efde31f97 ("drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1()") Reported-by: Jerry Zuo Cc: Jerry Zuo Cc: Harry Wentland Cc: # v4.6+ Reviewed-by: Dave Airlie Link: https://patchwork.freedesktop.org/patch/msgid/20181113224613.28809-1-lyude@redhat.com Signed-off-by: Sean Paul Signed-off-by: Sasha Levin --- drivers/gpu/drm/drm_dp_mst_topology.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index e05dda92398c6..17aedaaf364c1 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -980,9 +980,20 @@ static struct drm_dp_mst_port *drm_dp_mst_get_port_ref_locked(struct drm_dp_mst_ static struct drm_dp_mst_port *drm_dp_get_validated_port_ref(struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port) { struct drm_dp_mst_port *rport = NULL; + mutex_lock(&mgr->lock); - if (mgr->mst_primary) - rport = drm_dp_mst_get_port_ref_locked(mgr->mst_primary, port); + /* + * Port may or may not be 'valid' but we don't care about that when + * destroying the port and we are guaranteed that the port pointer + * will be valid until we've finished + */ + if (current_work() == &mgr->destroy_connector_work) { + kref_get(&port->kref); + rport = port; + } else if (mgr->mst_primary) { + rport = drm_dp_mst_get_port_ref_locked(mgr->mst_primary, + port); + } mutex_unlock(&mgr->lock); return rport; } -- 2.20.1