On 13/06/2023 01:02, Bjorn Andersson wrote:
The DP component's unbind operation walks through the submodules to
unregister and clean things up. But if the unbind happens because the DP
controller itself is being removed, all the memory for those submodules
has just been freed.
Change the order of these operations to avoid the many use-after-free
that otherwise happens in this code path.
Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
Signed-off-by: Bjorn Andersson <quic_bjorande@xxxxxxxxxxx>
---
drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index bbb0550a022b..ebc84b8fddf8 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1337,9 +1337,9 @@ static int dp_display_remove(struct platform_device *pdev)
{
struct dp_display_private *dp = dev_get_dp_display_private(&pdev->dev);
+ component_del(&pdev->dev, &dp_display_comp_ops);
dp_display_deinit_sub_modules(dp);
- component_del(&pdev->dev, &dp_display_comp_ops);
platform_set_drvdata(pdev, NULL);
This matches more or less the order in dp_display_probe().
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
A note for the possible followup: the driver initializes DP debugfs from
dpu_kms (ugh) by calling msm_dp_debugfs_init() -> dp_debug_get(). I
think that dp_debug_put() in dp_display_deinit_sub_modules() does not
look correct.
return 0;
--
With best wishes
Dmitry
