Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [Critical] Missing `cancel_work_sync(&dp->hpd_work)` during unbind allows the workqueue to execute after the device is unbound and removed, leading to a Use-After-Free. -- --- Patch [1]: [PATCH v4 01/10] drm/bridge: synopsys: dw-dp: Fix incorrect resource lifetimes in bind callback --- commit ad3d9fe60dfef89b2bbe919cc696921df60e683f Author: Sebastian Reichel <[email protected]> drm/bridge: synopsys: dw-dp: Fix incorrect resource lifetimes in bind callback This commit introduces a new probe helper function to acquire resources early rather than during the bind callback. This aligns resource allocation with device lifecycle instead of driver bind and unbind time. > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c > b/drivers/gpu/drm/bridge/synopsys/dw-dp.c > --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c [ ... ] > +void dw_dp_unbind(struct dw_dp *dp) > +{ > + disable_irq(dp->irq); > phy_exit(dp->phy); > + drm_dp_aux_unregister(&dp->aux); > + drm_bridge_remove(&dp->bridge); > } [Severity: Critical] This is a pre-existing issue, but could this leave pending work items running after the device is unbound? If an HPD interrupt fires right before or during dw_dp_unbind(), the interrupt handler schedules dp->hpd_work. While disable_irq() prevents new interrupts, it doesn't cancel already pending work. When the driver is subsequently removed and the devm-allocated dp structure is freed, the system workqueue could execute dw_dp_hpd_work() and trigger a use-after-free on the released memory. Would it be appropriate to add cancel_work_sync(&dp->hpd_work) here during the teardown sequence? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/20260721-synopsys-dw-dp-improvements-v4-0-f0f4a4ede...@collabora.com?part=1
