There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks are meant to protect against.

More importantly though, we're about to stop clearing mstc->port in the
next commit, which means if we could potentially hit a use-after-free
error if we tried to check mstc->port->vcpi here. So to make life easier
for anyone who bisects this code in the future, use msto->disabled
instead to check whether or not we need to deallocate VCPI instead.

Signed-off-by: Lyude Paul <ly...@redhat.com>
Reviewed-By: Ben Skeggs <bske...@redhat.com>
Cc: Daniel Vetter <dan...@ffwll.ch>
Cc: David Airlie <airl...@redhat.com>
Cc: Jerry Zuo <jerry....@amd.com>
Cc: Harry Wentland <harry.wentl...@amd.com>
Cc: Juston Li <juston...@intel.com>
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 800213be76ea..28538ef19b71 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -703,14 +703,17 @@ nv50_msto_cleanup(struct nv50_msto *msto)
        struct nv50_mstc *mstc = msto->mstc;
        struct nv50_mstm *mstm = mstc->mstm;
 
+       if (!msto->disabled)
+               return;
+
        NV_ATOMIC(drm, "%s: msto cleanup\n", msto->encoder.name);
-       if (mstc->port && mstc->port->vcpi.vcpi > 0 && !nv50_msto_payload(msto))
+
+       if (mstc->port)
                drm_dp_mst_deallocate_vcpi(&mstm->mgr, mstc->port);
-       if (msto->disabled) {
-               msto->mstc = NULL;
-               msto->head = NULL;
-               msto->disabled = false;
-       }
+
+       msto->mstc = NULL;
+       msto->head = NULL;
+       msto->disabled = false;
 }
 
 static void
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to