Re: [PATCH v2 31/37] drm/omap: dsi: Switch to atomic bridge callbacks

[sashiko-bot@kernel.org]

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 <mripard@kernel.org>

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/20260707-drm-all-atomic-bridges-v2-0-21d03cbca446@kernel.org?part=31