From: Lyude Paul <lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Cc: Jerry Zuo <Jerry.Zuo-5C7GfCeVMHo@public.gmane.org>,
Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>,
David Airlie <airlied-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Harry Wentland <harry.wentland-5C7GfCeVMHo@public.gmane.org>,
Juston Li <juston.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: [PATCH v7 07/20] drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails
Date: Thu, 10 Jan 2019 19:53:30 -0500 [thread overview]
Message-ID: <20190111005343.17443-8-lyude@redhat.com> (raw)
In-Reply-To: <20190111005343.17443-1-lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
While this isn't a complete fix, this will improve the reliability of
drm_dp_get_last_connected_port_and_mstb() pretty significantly during
hotplug events, since there's a chance that the in-memory topology tree
may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
is called and thus might end up causing our search to fail on an mstb
whose topology refcount has reached 0, but has not yet been removed from
it's parent.
Ideally, we should further fix this problem by ensuring that we deal
with the potential for racing with a hotplug event, which would look
like this:
* drm_dp_payload_send_msg() retrieves the last living relative of mstb
with drm_dp_get_last_connected_port_and_mstb()
* drm_dp_payload_send_msg() starts building payload message
At the same time, mstb gets unplugged from the topology and is no
longer the actual last living relative of the original mstb
* drm_dp_payload_send_msg() tries sending the payload message, hub times
out
* Hub timed out, we give up and run away-resulting in the payload being
leaked
This could be fixed by restarting the
drm_dp_get_last_connected_port_and_mstb() search whenever we get a
timeout, sending the payload to the new mstb, then repeating until
either the entire topology is removed from the system or
drm_dp_get_last_connected_port_and_mstb() fails. But since the above
race condition is not terribly likely, we'll address that in a later
patch series once we've improved the recovery handling for VCPI
allocations in the rest of the DP MST helpers.
Changes since v1:
* Convert kerneldoc for drm_dp_get_last_connected_port_and_mstb to
normal comment - danvet
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@redhat.com>
Cc: Jerry Zuo <Jerry.Zuo@amd.com>
Cc: Juston Li <juston.li@intel.com>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 44 +++++++++++++++++++++------
1 file changed, 34 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index 796985609933..7a251905b3c4 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2048,24 +2048,40 @@ static struct drm_dp_mst_port *drm_dp_get_last_connected_port_to_mstb(struct drm
return drm_dp_get_last_connected_port_to_mstb(mstb->port_parent->parent);
}
-static struct drm_dp_mst_branch *drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
- struct drm_dp_mst_branch *mstb,
- int *port_num)
+/*
+ * Searches upwards in the topology starting from mstb to try to find the
+ * closest available parent of mstb that's still connected to the rest of the
+ * topology. This can be used in order to perform operations like releasing
+ * payloads, where the branch device which owned the payload may no longer be
+ * around and thus would require that the payload on the last living relative
+ * be freed instead.
+ */
+static struct drm_dp_mst_branch *
+drm_dp_get_last_connected_port_and_mstb(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb,
+ int *port_num)
{
struct drm_dp_mst_branch *rmstb = NULL;
struct drm_dp_mst_port *found_port;
+
mutex_lock(&mgr->lock);
- if (mgr->mst_primary) {
+ if (!mgr->mst_primary)
+ goto out;
+
+ do {
found_port = drm_dp_get_last_connected_port_to_mstb(mstb);
+ if (!found_port)
+ break;
- if (found_port) {
+ if (drm_dp_mst_topology_try_get_mstb(found_port->parent)) {
rmstb = found_port->parent;
- if (drm_dp_mst_topology_try_get_mstb(rmstb))
- *port_num = found_port->port_num;
- else
- rmstb = NULL;
+ *port_num = found_port->port_num;
+ } else {
+ /* Search again, starting from this parent */
+ mstb = found_port->parent;
}
- }
+ } while (!rmstb);
+out:
mutex_unlock(&mgr->lock);
return rmstb;
}
@@ -2114,6 +2130,14 @@ static int drm_dp_payload_send_msg(struct drm_dp_mst_topology_mgr *mgr,
drm_dp_queue_down_tx(mgr, txmsg);
+ /*
+ * FIXME: there is a small chance that between getting the last
+ * connected mstb and sending the payload message, the last connected
+ * mstb could also be removed from the topology. In the future, this
+ * needs to be fixed by restarting the
+ * drm_dp_get_last_connected_port_and_mstb() search in the event of a
+ * timeout if the topology is still connected to the system.
+ */
ret = drm_dp_mst_wait_tx_reply(mstb, txmsg);
if (ret > 0) {
if (txmsg->reply.reply_type == 1)
--
2.20.1
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
next prev parent reply other threads:[~2019-01-11 0:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-11 0:53 [PATCH v7 00/20] MST refcounting/atomic helpers cleanup Lyude Paul
2019-01-11 0:53 ` [PATCH v7 03/20] drm/dp_mst: Fix some formatting in drm_dp_mst_allocate_vcpi() Lyude Paul
[not found] ` <20190111005343.17443-1-lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2019-01-11 0:53 ` [PATCH v7 01/20] drm/dp_mst: Fix some formatting in drm_dp_add_port() Lyude Paul
2019-01-11 0:53 ` [PATCH v7 02/20] drm/dp_mst: Fix some formatting in drm_dp_payload_send_msg() Lyude Paul
2019-01-11 0:53 ` [PATCH v7 04/20] drm/dp_mst: Fix some formatting in drm_dp_mst_deallocate_vcpi() Lyude Paul
2019-01-11 0:53 ` [PATCH v7 05/20] drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends Lyude Paul
2019-01-11 0:53 ` [PATCH v7 06/20] drm/dp_mst: Introduce new refcounting scheme for mstbs and ports Lyude Paul
2019-01-11 0:53 ` Lyude Paul [this message]
2019-01-11 0:53 ` [PATCH v7 08/20] drm/dp_mst: Stop releasing VCPI when removing ports from topology Lyude Paul
2019-01-11 0:53 ` [PATCH v7 10/20] drm/i915: Keep malloc references to MST ports Lyude Paul
2019-01-11 0:53 ` [PATCH v7 11/20] drm/amdgpu/display: Keep malloc ref to MST port Lyude Paul
2019-01-11 0:53 ` [PATCH v7 13/20] drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup() Lyude Paul
2019-01-11 0:53 ` [PATCH v7 14/20] drm/nouveau: Keep malloc references to MST ports Lyude Paul
2019-01-11 0:53 ` [PATCH v7 15/20] drm/nouveau: Stop unsetting mstc->port, use malloc refs Lyude Paul
2019-01-11 0:53 ` [PATCH v7 16/20] drm/nouveau: Grab payload lock in nv50_msto_payload() Lyude Paul
2019-01-11 0:53 ` [PATCH v7 17/20] drm/dp_mst: Add some atomic state iterator macros Lyude Paul
2019-01-11 0:53 ` [PATCH v7 18/20] drm/dp_mst: Start tracking per-port VCPI allocations Lyude Paul
2019-01-11 0:53 ` [PATCH v7 09/20] drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs Lyude Paul
2019-01-11 0:53 ` [PATCH v7 12/20] drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector() Lyude Paul
2019-01-11 0:53 ` [PATCH v7 19/20] drm/dp_mst: Check payload count in drm_dp_mst_atomic_check() Lyude Paul
2019-01-11 0:53 ` [PATCH v7 20/20] drm/nouveau: Use atomic VCPI helpers for MST Lyude Paul
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190111005343.17443-8-lyude@redhat.com \
--to=lyude-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=Jerry.Zuo-5C7GfCeVMHo@public.gmane.org \
--cc=airlied-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=daniel-/w4YWyX8dFk@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=harry.wentland-5C7GfCeVMHo@public.gmane.org \
--cc=intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=juston.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox