Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1560745imu; Thu, 22 Nov 2018 19:01:02 -0800 (PST) X-Google-Smtp-Source: AJdET5fwi0C8VRadiubKonqI7+hTgJyO2WIJZBW7oWwocer53BebNjNk80plnMkQODXgs5/SDOol X-Received: by 2002:a62:8096:: with SMTP id j144mr14314766pfd.140.1542942062182; Thu, 22 Nov 2018 19:01:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542942061; cv=none; d=google.com; s=arc-20160816; b=YpEc/yibhJ/FxP411irbawgx4S2L4EoYWLO7h4F6SGv31Vg8/VlaYWCev/JY7kO+yG 7DzzfROHQwvrUblksU9DZA8xoU2tuNAPXaxYtf8yN42eybk5SYVH+p+K9eLMGBxHGLm9 P8PD6xPU5NzgvN98JNMU5nHHN8JO5+joZhpu9U2hGkomliTeAgY9HNU4IPYca55RKFL+ R3OWbaXjMo5iIeUYSY2MAKRSqMzajppAM5Sa2iLnGxON1YoTQIYo3UyWy1mIW4QqCZOs ZkrigiUu5FVvbc3mLPmje2zC2A4ly/NTq77Me+mEuPAXTykB4TDcJpBPOSwv0/kKzzKl 3Gug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=v4klK6xFxSzgYgiv0rt7hN7g6hxIeJ+LKUwjjOZI/8Y=; b=gDAxB24FXGwC8sWTXO+WSSvIMOuLm4IRnPJjYTyjR0Pb21sWcvlbGBLiOvwvA+7T32 tfhua4ZSPjptO/BqBUtJxrbna4EF0/yuvIjojk3+XkVRNfhNJaQAWEgtl4c6SLNYDVYs qiSAUjUOzbIzkLCapRUoXUS/duIjzKkjF480DPgRVzUqVjqjrOu592HXvphNYabHamUh YrBNBjT0MctJvEdKMpnMVVw4xmxzPAO1w5d8mjls7xGEmHPlf4MISN2TI7W6yNrfSDpV X2Nm6R3kAjcqGnYLPDtAfvEk+iw7Ep3Q/PmFuIv3Qig5zCN6516yHf0hctbzeRJ6RgzW Qs8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=ZWytbgTU; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b14si31890396plk.333.2018.11.22.19.00.45; Thu, 22 Nov 2018 19:01: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; dkim=pass header.i=@ffwll.ch header.s=google header.b=ZWytbgTU; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405095AbeKVTMz (ORCPT + 99 others); Thu, 22 Nov 2018 14:12:55 -0500 Received: from mail-it1-f196.google.com ([209.85.166.196]:54021 "EHLO mail-it1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405086AbeKVTMz (ORCPT ); Thu, 22 Nov 2018 14:12:55 -0500 Received: by mail-it1-f196.google.com with SMTP id g85so12998449ita.3 for ; Thu, 22 Nov 2018 00:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v4klK6xFxSzgYgiv0rt7hN7g6hxIeJ+LKUwjjOZI/8Y=; b=ZWytbgTUBMQHxVhNY/uu9TRhVwzRxczNjV0rouM5qhn7m1Izv8Qelf1lPeaEebYhFy lya5nwN4yfZtSgnpSiucwPFLENEZQT1JH8SrIz6F2a0ICasSiaElNFGc1Ej6uWovUVc4 64dKMmRnkRjKVZLm3KOnDaPiNqOcSXAa208lM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v4klK6xFxSzgYgiv0rt7hN7g6hxIeJ+LKUwjjOZI/8Y=; b=pf0iGW6fhn5OyTSM0sqDpu9a8RgrS/QI9vSzCKz9N/cwu97TU2YwucrFVzs7H3D9jW kIRJh7AMcwXE8r2MnUttcEvatBQuoZ/n9CpQAfpgJkys7pcpkuUwqkqprLRKWHcOpJcZ JOYi59Q6I5cftMtPFae2edzey+4c2heZSEyVgwQqB7a3cRUxPRctf5RaMOhvmthLwqCd unDFF1/LAgWt1SK6R1bHfI2whV618dpHeG3eUOMEQzphmYQYJJB/olfjKo9xwA4przbw UBo3gIgDDyQDEWbh2n2X7SW1v8bDBDsG1uchaowueyKSXomMrr1UBsskxHDscsM7iSL4 R60w== X-Gm-Message-State: AA+aEWbYNnzccEjGYQohnTIQQh5s6WI2c2jarvdyF1y9a64UE0ePSk2A JzxwyG3e/nNI64JqFtq4iOED0N3L7Udx2lDLRwh8xQ== X-Received: by 2002:a24:21d4:: with SMTP id e203-v6mr7150652ita.51.1542875668730; Thu, 22 Nov 2018 00:34:28 -0800 (PST) MIME-Version: 1.0 References: <20181113224613.28809-1-lyude@redhat.com> In-Reply-To: <20181113224613.28809-1-lyude@redhat.com> From: Daniel Vetter Date: Thu, 22 Nov 2018 09:34:16 +0100 Message-ID: Subject: Re: [PATCH] drm/dp_mst: Skip validating ports during destruction, just ref To: Lyude Cc: dri-devel , Maxime Ripard , Sean Paul , Linux Kernel Mailing List , stable , Dave Airlie , Jerry Zuo Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 13, 2018 at 11:47 PM Lyude Paul wrote: > > 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+ Hm, sounds very similar to the bug I pointed out in your "make vcpi alloc more atomic" series. Will this all interact nicely with the solution we've worked out there (where we need to delay at least the kfree(port) until the last vcpi allocation is released? -Daniel > --- > 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 529414556962..08978ad72f33 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -1023,9 +1023,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.19.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch