The patch below does not apply to the 5.13-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 3769e4c0af5b82c8ea21d037013cb9564dfaa51f Mon Sep 17 00:00:00 2001
From: Wayne Lin Wayne.Lin@amd.com Date: Wed, 16 Jun 2021 11:55:01 +0800 Subject: [PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale topology
[Why] After unplug/hotplug hub from the system, userspace might start to clear stale payloads gradually. If we call drm_dp_mst_deallocate_vcpi() to release stale VCPI of those ports which are not relating to current topology, we have chane to wrongly clear active payload table entry for current topology.
E.g. We have allocated VCPI 1 in current payload table and we call drm_dp_mst_deallocate_vcpi() to clean VCPI 1 in stale topology. In drm_dp_mst_deallocate_vcpi(), it will call drm_dp_mst_put_payload_id() tp put VCPI 1 and which means ID 1 is available again. Thereafter, if we want to allocate a new payload stream, it will find ID 1 is available by drm_dp_mst_assign_payload_id(). However, ID 1 is being used
[How] Check target sink is relating to current topology or not before doing any payload table update. Searching upward to find the target sink's relevant root branch device. If the found root branch device is not the same root of current topology, don't update payload table.
Changes since v1: * Change debug macro to use drm_dbg_kms() instead * Amend the commit message to add Cc tag.
Signed-off-by: Wayne Lin Wayne.Lin@amd.com Cc: stable@vger.kernel.org Signed-off-by: Lyude Paul lyude@redhat.com Link: https://patchwork.freedesktop.org/patch/msgid/20210616035501.3776-3-Wayne.Li... Reviewed-by: Lyude Paul lyude@redhat.com
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index b41b837db66d..9ac148efd9e4 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -94,6 +94,9 @@ static int drm_dp_mst_register_i2c_bus(struct drm_dp_mst_port *port); static void drm_dp_mst_unregister_i2c_bus(struct drm_dp_mst_port *port); static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr);
+static bool drm_dp_mst_port_downstream_of_branch(struct drm_dp_mst_port *port, + struct drm_dp_mst_branch *branch); + #define DBG_PREFIX "[dp_mst]"
#define DP_STR(x) [DP_ ## x] = #x @@ -3366,6 +3369,7 @@ int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr) struct drm_dp_mst_port *port; int i, j; int cur_slots = 1; + bool skip;
mutex_lock(&mgr->payload_lock); for (i = 0; i < mgr->max_payloads; i++) { @@ -3380,6 +3384,14 @@ int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr) port = container_of(vcpi, struct drm_dp_mst_port, vcpi);
+ mutex_lock(&mgr->lock); + skip = !drm_dp_mst_port_downstream_of_branch(port, mgr->mst_primary); + mutex_unlock(&mgr->lock); + + if (skip) { + drm_dbg_kms("Virtual channel %d is not in current topology\n", i); + continue; + } /* Validated ports don't matter if we're releasing * VCPI */ @@ -3479,6 +3491,7 @@ int drm_dp_update_payload_part2(struct drm_dp_mst_topology_mgr *mgr) struct drm_dp_mst_port *port; int i; int ret = 0; + bool skip;
mutex_lock(&mgr->payload_lock); for (i = 0; i < mgr->max_payloads; i++) { @@ -3488,6 +3501,13 @@ int drm_dp_update_payload_part2(struct drm_dp_mst_topology_mgr *mgr)
port = container_of(mgr->proposed_vcpis[i], struct drm_dp_mst_port, vcpi);
+ mutex_lock(&mgr->lock); + skip = !drm_dp_mst_port_downstream_of_branch(port, mgr->mst_primary); + mutex_unlock(&mgr->lock); + + if (skip) + continue; + drm_dbg_kms(mgr->dev, "payload %d %d\n", i, mgr->payloads[i].payload_state); if (mgr->payloads[i].payload_state == DP_PAYLOAD_LOCAL) { ret = drm_dp_create_payload_step2(mgr, port, mgr->proposed_vcpis[i]->vcpi, &mgr->payloads[i]); @@ -4574,9 +4594,18 @@ EXPORT_SYMBOL(drm_dp_mst_reset_vcpi_slots); void drm_dp_mst_deallocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port) { + bool skip; + if (!port->vcpi.vcpi) return;
+ mutex_lock(&mgr->lock); + skip = !drm_dp_mst_port_downstream_of_branch(port, mgr->mst_primary); + mutex_unlock(&mgr->lock); + + if (skip) + return; + drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi); port->vcpi.num_slots = 0; port->vcpi.pbn = 0;
[AMD Official Use Only]
Hi Greg,
Really thanks for your time. About failing to apply below patches to stable tree: 3769e4c0af5b82c8ea21d037013cb9564dfaa51f [PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale topology
35d3e8cb35e75450f87f87e3d314e2d418b6954b [PATCH] drm/dp_mst: Do not set proposed vcpi directly
There was an immediate following patch to correct the issue caused by above patches: 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c [PATCH] drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()
In other words, these three patches should be committed at the same time. Sorry for any inconvenience it brought. Please advise me if there is anything else to do for having these patches applied to stable tree. Really thanks for your help.
Regards, Wayne
-----Original Message----- From: gregkh@linuxfoundation.org gregkh@linuxfoundation.org Sent: Thursday, July 15, 2021 8:17 PM To: Lin, Wayne Wayne.Lin@amd.com; lyude@redhat.com Cc: stable@vger.kernel.org Subject: FAILED: patch "[PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale" failed to apply to 5.13-stable tree
The patch below does not apply to the 5.13-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 3769e4c0af5b82c8ea21d037013cb9564dfaa51f Mon Sep 17 00:00:00 2001 From: Wayne Lin Wayne.Lin@amd.com Date: Wed, 16 Jun 2021 11:55:01 +0800 Subject: [PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale topology
[Why] After unplug/hotplug hub from the system, userspace might start to clear stale payloads gradually. If we call drm_dp_mst_deallocate_vcpi() to release stale VCPI of those ports which are not relating to current topology, we have chane to wrongly clear active payload table entry for current topology.
E.g. We have allocated VCPI 1 in current payload table and we call drm_dp_mst_deallocate_vcpi() to clean VCPI 1 in stale topology. In drm_dp_mst_deallocate_vcpi(), it will call drm_dp_mst_put_payload_id() tp put VCPI 1 and which means ID 1 is available again. Thereafter, if we want to allocate a new payload stream, it will find ID 1 is available by drm_dp_mst_assign_payload_id(). However, ID 1 is being used
[How] Check target sink is relating to current topology or not before doing any payload table update. Searching upward to find the target sink's relevant root branch device. If the found root branch device is not the same root of current topology, don't update payload table.
Changes since v1:
- Change debug macro to use drm_dbg_kms() instead
- Amend the commit message to add Cc tag.
Signed-off-by: Wayne Lin Wayne.Lin@amd.com Cc: stable@vger.kernel.org Signed-off-by: Lyude Paul lyude@redhat.com Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchwork.... 035501.3776-3- Wayne.Lin%40amd.com&data=04%7C01%7CWayne.Lin%40amd.com%7C231171835e1e4d40019a08d9478c7553%7C3dd8961fe488 4e608e11a82d994e183d%7C0%7C0%7C637619490858271159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ry%2FBe6oKXqA51GAiVYSsl4RqIoGZ%2BT9%2FsVbqMD1OlXc%3D&r eserved=0 Reviewed-by: Lyude Paul lyude@redhat.com
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index b41b837db66d..9ac148efd9e4 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -94,6 +94,9 @@ static int drm_dp_mst_register_i2c_bus(struct drm_dp_mst_port *port); static void drm_dp_mst_unregister_i2c_bus(struct drm_dp_mst_port *port); static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr);
+static bool drm_dp_mst_port_downstream_of_branch(struct drm_dp_mst_port *port,
struct drm_dp_mst_branch *branch);
#define DBG_PREFIX "[dp_mst]"
#define DP_STR(x) [DP_ ## x] = #x @@ -3366,6 +3369,7 @@ int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr) struct drm_dp_mst_port *port; int i, j; int cur_slots = 1;
bool skip; mutex_lock(&mgr->payload_lock); for (i = 0; i < mgr->max_payloads; i++) { @@ -3380,6 +3384,14 @@ int drm_dp_update_payload_part1(struct
drm_dp_mst_topology_mgr *mgr) port = container_of(vcpi, struct drm_dp_mst_port, vcpi);
mutex_lock(&mgr->lock);
skip = !drm_dp_mst_port_downstream_of_branch(port, mgr->mst_primary);
mutex_unlock(&mgr->lock);
if (skip) {
drm_dbg_kms("Virtual channel %d is not in current topology\n", i);
continue;
} /* Validated ports don't matter if we're releasing * VCPI */
@@ -3479,6 +3491,7 @@ int drm_dp_update_payload_part2(struct drm_dp_mst_topology_mgr *mgr) struct drm_dp_mst_port *port; int i; int ret = 0;
bool skip; mutex_lock(&mgr->payload_lock); for (i = 0; i < mgr->max_payloads; i++) { @@ -3488,6 +3501,13 @@ int drm_dp_update_payload_part2(struct
drm_dp_mst_topology_mgr *mgr)
port = container_of(mgr->proposed_vcpis[i], struct drm_dp_mst_port, vcpi);
mutex_lock(&mgr->lock);
skip = !drm_dp_mst_port_downstream_of_branch(port, mgr->mst_primary);
mutex_unlock(&mgr->lock);
if (skip)
continue;
drm_dbg_kms(mgr->dev, "payload %d %d\n", i, mgr->payloads[i].payload_state); if (mgr->payloads[i].payload_state == DP_PAYLOAD_LOCAL) { ret = drm_dp_create_payload_step2(mgr, port, mgr->proposed_vcpis[i]->vcpi, &mgr->payloads[i]); @@ -
4574,9 +4594,18 @@ EXPORT_SYMBOL(drm_dp_mst_reset_vcpi_slots); void drm_dp_mst_deallocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port) {
bool skip;
if (!port->vcpi.vcpi) return;
mutex_lock(&mgr->lock);
skip = !drm_dp_mst_port_downstream_of_branch(port, mgr->mst_primary);
mutex_unlock(&mgr->lock);
if (skip)
return;
drm_dp_mst_put_payload_id(mgr, port->vcpi.vcpi); port->vcpi.num_slots = 0; port->vcpi.pbn = 0;
On Thu, Jul 15, 2021 at 03:07:19PM +0000, Lin, Wayne wrote:
[AMD Official Use Only]
Hi Greg,
Really thanks for your time. About failing to apply below patches to stable tree: 3769e4c0af5b82c8ea21d037013cb9564dfaa51f [PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale topology
35d3e8cb35e75450f87f87e3d314e2d418b6954b [PATCH] drm/dp_mst: Do not set proposed vcpi directly
There was an immediate following patch to correct the issue caused by above patches: 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c [PATCH] drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()
In other words, these three patches should be committed at the same time. Sorry for any inconvenience it brought. Please advise me if there is anything else to do for having these patches applied to stable tree. Really thanks for your help.
These commits do not apply to the current stable trees, so please submit backports of them for how ever far back you wish to see them, so that we can apply them.
thanks,
greg k-h
[AMD Official Use Only]
-----Original Message----- From: gregkh@linuxfoundation.org gregkh@linuxfoundation.org Sent: Friday, July 16, 2021 1:28 AM To: Lin, Wayne Wayne.Lin@amd.com Cc: lyude@redhat.com; stable@vger.kernel.org Subject: Re: FAILED: patch "[PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale" failed to apply to 5.13-stable tree
On Thu, Jul 15, 2021 at 03:07:19PM +0000, Lin, Wayne wrote:
[AMD Official Use Only]
Hi Greg,
Really thanks for your time. About failing to apply below patches to stable tree: 3769e4c0af5b82c8ea21d037013cb9564dfaa51f [PATCH] drm/dp_mst: Avoid to mess up payload table by ports in stale topology
35d3e8cb35e75450f87f87e3d314e2d418b6954b [PATCH] drm/dp_mst: Do not set proposed vcpi directly
There was an immediate following patch to correct the issue caused by above patches: 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c [PATCH] drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()
In other words, these three patches should be committed at the same time. Sorry for any inconvenience it brought. Please advise me if there is anything else to do for having these patches applied to stable tree. Really thanks for your help.
These commits do not apply to the current stable trees, so please submit backports of them for how ever far back you wish to see them, so that we can apply them.
Hi Greg,
I see. Thanks for your time! Will do.
Regards, Wayne
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org