Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] The `te_timeout_work` is cancelled asynchronously during driver detach, causing a possible Use-After-Free. -- --- Patch [31]: [PATCH v2 31/37] drm/omap: dsi: Switch to atomic bridge callbacks --- commit 7b874c0db789f5326cf81422dc10c73534a0a3cf Author: Maxime Ripard <[email protected]> drm/omap: dsi: Switch to atomic bridge callbacks This commit switches the legacy non-atomic enable and disable bridge callbacks in the OMAP DSI driver to their atomic counterparts. It also adds the necessary atomic state handlers to support removing legacy bridge callback support from the DRM bridge core. > diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c > b/drivers/gpu/drm/omapdrm/dss/dsi.c > index 27fe7bca9e2cf..7aaee94f86e41 100644 > --- a/drivers/gpu/drm/omapdrm/dss/dsi.c > +++ b/drivers/gpu/drm/omapdrm/dss/dsi.c [ ... ] [Severity: High] This is a pre-existing issue, but can this asynchronous cancellation lead to a use-after-free during driver detach? Looking at driver detach paths, omap_dsi_host_detach() calls omap_dsi_unregister_te_irq(), which uses the asynchronous cancellation: drivers/gpu/drm/omapdrm/dss/dsi.c:omap_dsi_unregister_te_irq() { ... cancel_delayed_work(&dsi->te_timeout_work); ... } Because it does not wait for a currently executing work callback to finish, could dsi_remove() and devres cleanup complete while omap_dsi_te_timeout_work_callback() is still running? If the devres cleanup frees the dsi struct (allocated via devm_drm_bridge_alloc()), would the concurrent callback then dereference the freed dsi pointer? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=31
