Re: [PATCH v5 06/14] media: iris: Add context bank hooks for platform specific initialization

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Teardown order violation in `iris_remove()` creates a race condition with userspace, potentially leading to Use-After-Free or IOMMU faults.
--

commit 4def10f3c3b40c622d9f01893a1225d37915f0d3
Author: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>

media: iris: Add context bank hooks for platform specific initialization

This commit adds initialization and deinitialization hooks in the platform
data for context bank setup. These hooks allow platform-specific code to
configure dedicated firmware context bank devices mapped to the firmware
stream ID.

> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
> --- a/drivers/media/platform/qcom/iris/iris_probe.c
> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
[ ... ]
> @@ -193,6 +207,7 @@ static void iris_remove(struct platform_device *pdev)
>  		return;
>  
>  	iris_core_deinit(core);
> +	iris_deinit_cb_devs(core);
>  
>  	video_unregister_device(core->vdev_dec);
>  	video_unregister_device(core->vdev_enc);

Could this teardown order create a race condition with userspace?

The patch calls iris_deinit_cb_devs() before video_unregister_device(),
which leaves a window where the hardware context banks are destroyed while
the v4l2 character devices remain registered and accessible to userspace.

If userspace calls open() on the device during this window, the standard
v4l2_open() will succeed and could eventually call into iris_core_init().
Since iris_core_init() acquires the core lock, detects the deinit state,
and calls iris_fw_load(), it could attempt to load the firmware while the
context banks are being torn down.

Attempting to use destroyed context banks for DMA or firmware mapping could
result in IOMMU faults or memory corruption.

While the pre-existing code already called iris_core_deinit() before
unregistering the video devices, this patch introduces a new failure mode
by explicitly tearing down the context banks during this exposed window.

Should iris_deinit_cb_devs() be called after the video devices are fully
unregistered, similar to the LIFO teardown order followed in the
iris_probe() error paths?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260509-glymur-v5-0-7fbb340c5dbd@oss.qualcomm.com?part=6