Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp310931imu; Wed, 21 Nov 2018 20:37:11 -0800 (PST) X-Google-Smtp-Source: AFSGD/Uu1127nNJoQ0NXptPlLwq+Kh3vvJQl+vdqJBWkyPFhOhunMtRRZ/e8iwBzNAoKMnPgIWIx X-Received: by 2002:a63:8742:: with SMTP id i63mr8549586pge.298.1542861431368; Wed, 21 Nov 2018 20:37:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542861431; cv=none; d=google.com; s=arc-20160816; b=0oj8bHvXUZdcOEmLuBV40DCRbxxxc0/Q82Dg5+Notusb9jOZ+BhGIrOPZRBgsN3R/e uZ1FpwBDo+6SBiO38V43bJcw8x2MHHLFgUD8iDsVrAaCuwdfGL2YhkhlHY3RevgkL0tE M0p85SSWdKHtXQG6JVLhDH/gs6nwg1CaFuX9m9W/ouJbTZLsLkGEdDYwpMW9rZxS+9fa 2QfSc0wgl7/PtBfVU5LYWL6ZP9UtIpUogd7c3VlwvI+MizQ2qbqxwksYeUk3IMP2YMKp UYtZ8fFH2jVwTOF28lM+3Cauaw6cunrYMj9ANx7affT34QJUZ4/ySur7990SW/mGbzMz Ss4w== 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=bT3fk8KWsBxpBwDBl8XHsS2Td8g+vg+s4Ji6q3aMgD0=; b=aAmqx9Nb6b1Qne7RFpZLzrLyNu5kDp4G7JFiEgo/ODdYVmb7PoqRCmwlQzcXUl8XKD 5zk5+B1HD99p5HIpy60os16E9L0R+WUmhgL/oKTfpkJQOZYch+/zbnGryQTw4sc5gUoB kxvNA1pg3786IRqP//0GSBjxJOVBiNZ1Q4v1jmLb0OffmWeQQG6Otwuak9j45AGYwfa1 Diye/FSyuvBIJx8mm4CwyEaU2PmFA5x7OXDJNmXvpkrSm4XzCsg2E66gODAAAIh7++3F se5yaYBwdyMM9RiwwGmpsoQuL1oXdJlZbOmKA6R+LH8As3HNj/QX1q8RkdjM8sAGVcVl hOIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=jxYffYbv; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r18si14756919pls.115.2018.11.21.20.36.56; Wed, 21 Nov 2018 20:37:11 -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=@gmail.com header.s=20161025 header.b=jxYffYbv; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388959AbeKVGoH (ORCPT + 99 others); Thu, 22 Nov 2018 01:44:07 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:39289 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730156AbeKVGoG (ORCPT ); Thu, 22 Nov 2018 01:44:06 -0500 Received: by mail-qt1-f193.google.com with SMTP id n21so5216029qtl.6; Wed, 21 Nov 2018 12:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bT3fk8KWsBxpBwDBl8XHsS2Td8g+vg+s4Ji6q3aMgD0=; b=jxYffYbvdnKT8HNmMd1rJzvcjZS9kagixnKiWT/pPwleSeqLYPMoPTWXuf7bzlkvYr URIc2c7i2qhrYH6loxPuT00wxR7U7MjDt01ii4cKz5+Bp07f3bp7KRJNu/VoUixlV0Rm NEgQef0kTy3Ym7P/cBuCJXYZfUWE2mb6otjK4yj0fhKEBzINSvmKYWqYTIBc7DUjA2qk tIXzfZiDMAWv8l6T57dUEZCPGesZjlUI+4mTZY3PBna3FltPx9yapjcYzAOJbR+/9frm auOVI5mlK2dU6tawUXBMUan4SJVQ6U+TlQMkyEu27vIlnU2x5/YqY3VMsGsbfsxw7J+6 Xq/Q== 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=bT3fk8KWsBxpBwDBl8XHsS2Td8g+vg+s4Ji6q3aMgD0=; b=pwqWPZ42pBMzm5WiBicDSpnulGUZUDtodaNKVk3x1ofsR6VigKa2ITgAOPIdY3o/8K aF3LE5KF5+lQvI4G7cVQktPmVTwstmDUoanCx9OceFiXXGfurd6+ShhodTCsQ6ROKHOl oTFqXIjgIbSHHPF1+hFGu8nOeEbjHk8JO1ayoUlaE1Gizv6NONefah9nszEjkS63cJ9d RU+fEWEthXkNTQis5VwEcexv/gCpYjJjf8lK2z79rrOjBVoYxMUwDBd3ay7E+MyPcIE1 j0Nsqm1VxS4JBJhifN/FB/xddlEPNcqXHZV+NXy7UYpxem5qIi2d1lcQVTHZVchXBGuE XJYQ== X-Gm-Message-State: AGRZ1gKgC/NzSyRHdhhdRJjkDoIVo6Z6vEQVHFD6GplNq8kXMLU1KlZR aFudhPAQCddAGyr3p+Skkk6Tjz7Q5LXcTH8AXNrfsQ== X-Received: by 2002:aed:310d:: with SMTP id 13mr7420179qtg.356.1542830899564; Wed, 21 Nov 2018 12:08:19 -0800 (PST) MIME-Version: 1.0 References: <20181113224613.28809-1-lyude@redhat.com> In-Reply-To: <20181113224613.28809-1-lyude@redhat.com> From: Dave Airlie Date: Thu, 22 Nov 2018 06:08:07 +1000 Message-ID: Subject: Re: [PATCH] drm/dp_mst: Skip validating ports during destruction, just ref To: Lyude Paul Cc: dri-devel , Maxime Ripard , sean@poorly.run, LKML , stable , Dave Airlie , Jerry.Zuo@amd.com 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 Wed, 14 Nov 2018 at 08:47, 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+ Much as I constantly feel we are missing some better way to do all of this, this seems like a reasonable fix. Reviewed-by: Dave Airlie > --- > 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