Re: [PATCH v8 7/8] drm/vc4: use drmm_writeback_connector_init()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the `vc4_txp_interrupt` handler can trigger a use-after-free on the `txp` structure if the component is unbound.
--

--- Patch [7]: [PATCH v8 7/8] drm/vc4: use drmm_writeback_connector_init() ---
Note: The format of this review has been altered to provide a free-form
summary of the findings due to recitation restrictions. The original patch
code is not directly quoted.

commit d2ba7084f0c0f5d055693e1cdaf9ce77bc6aa242
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

drm/vc4: use drmm_writeback_connector_init()

This commit changes the VC4 driver to use drmm_writeback_connector_init()
instead of drm_writeback_connector_init() to ensure proper cleanup of the
job queue. It also removes the vc4_txp_unbind function.

[Severity: High]
This isn't a bug introduced by this patch, but does the component unbind flow
leave a dangling interrupt handler that can cause a use-after-free?

In vc4_txp_bind(), the txp structure is allocated using drmm_kzalloc(), tying
its lifecycle to the DRM master aggregate device.

However, the interrupt handler vc4_txp_interrupt() is registered using
devm_request_irq() on the component platform device.

If the DRM master is unbound via sysfs, the drmm-managed txp structure is
freed. Because the component platform device driver is not necessarily unbound,
the devm-managed IRQ handler remains active.

If an interrupt fires after the DRM device teardown, won't vc4_txp_interrupt()
dereference the freed txp structure?

Should the IRQ registration be tied to the DRM lifecycle, or should the IRQ
be explicitly disabled when the component unbinds?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260723003205.330362-1-John.Harrison@Igalia.com?part=7