Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] drm/msm: Unresolved ABBA deadlock between runtime_suspend and IRQ thread --
commit 32f0e463b46b824d1b3126d8c017d6f4509a8c7b Author: Xilin Wu <[email protected]> drm/msm/dp: Keep runtime PM calls outside the connection lock This commit shifts runtime PM calls outside the connection lock in the plug, unplug, and detect handlers. The goal is to avoid holding the lock during synchronous PM operations that might deadlock with HPD IRQ threads. > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c > b/drivers/gpu/drm/msm/dp/dp_display.c > --- a/drivers/gpu/drm/msm/dp/dp_display.c > +++ b/drivers/gpu/drm/msm/dp/dp_display.c [ ... ] > @@ -488,10 +491,10 @@ static int msm_dp_hpd_unplug_handle(struct > msm_dp_display_private *dp) > dp->msm_dp_display.connector_type, > dp->link->sink_count); > > - if (dp->plugged) { > - pm_runtime_put_sync(&pdev->dev); > - dp->plugged = false; > - } > + dp->plugged = false; > + mutex_unlock(&dp->plugged_lock); > + > + pm_runtime_put_sync(&pdev->dev); [Severity: High] Does this still leave an ABBA deadlock, just shifted from the plugged_lock to the PM runtime wait queue? If a process thread (e.g., during unbind) calls this pm_runtime_put_sync() and drops the PM usage count to 0, it triggers msm_dp_pm_runtime_suspend(). The suspend callback calls disable_irq(dp->irq), which synchronously blocks waiting for the msm_dp_display_irq_thread to complete. However, if the IRQ thread is concurrently handling an event, it executes msm_dp_bridge_hpd_notify(), which unconditionally calls: msm_dp_bridge_hpd_notify() pm_runtime_resume_and_get(&msm_dp_display->pdev->dev) Because the device state is RPM_SUSPENDING, the IRQ thread blocks on the PM runtime wait queue waiting for the suspend to finish. The suspend thread is blocked on disable_irq() waiting for the IRQ thread, resulting in a deadlock. > > return 0; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=6
