[PATCH] media: mtk-jpeg: cancel workqueue on release for supported platforms only

[Nicolas Dufresne]

Le mercredi 01 avril 2026 à 11:44 +0200, Louis-Alexis Eyraud a écrit :
> Since a recent fix the mtk_jpeg_release function cancels any pending
> or running work present in the driver workqueue using
> cancel_work_sync function.
> Currently, only the multicore based variants use this workqueue and they
> have the jpeg_worker platform data field initialized with a workqueue
> callback function. For the others, this field value remain NULL by
> default.
> The cancel_work_sync function is unconditionally called in
> mtk_jpeg_release function, even for the variants that do not use the
> workqueue. This call generates a WARN_ON print in __flush_work because
> the workqueue callback function presence check fails in __flush_work
> function (used by cancel_work_sync).
> 
> So, to avoid these warnings, call cancel_work_sync only if a workqueue
> callback is defined in platform data.
> 
> Fixes: 34c519feef3e ("media: mtk-jpeg: fix use-after-free in release path due to uncancelled work")
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud at collabora.com>

Reviewed-by: Nicolas Dufresne <nicolas.dufresne at collabora.com>

> ---
> Patch to fix the following warning that occurs on boards such as
> Mediatek Genio 510-EVK:
> ```
> WARNING: kernel/workqueue.c:4291 at __flush_work+0x320/0x340, CPU#1:
>   v4l_id/409
> ...
> Call trace:
>  __flush_work+0x320/0x340 (P)
>  cancel_work_sync+0x6c/0x9c
>  mtk_jpeg_release+0x2c/0x84 [mtk_jpeg]
>  v4l2_release+0x8c/0xe8 [videodev]
>  __fput+0xcc/0x2e0
>  fput_close_sync+0x40/0x100
>  __arm64_sys_close+0x38/0x7c
>  invoke_syscall+0x54/0x10c
>  el0_svc_common.constprop.0+0xc0/0xe0
>  do_el0_svc+0x1c/0x34
>  el0_svc+0x34/0x108
>  el0t_64_sync_handler+0xa0/0xf0
>  el0t_64_sync+0x198/0x19c
> ---[ end trace 0000000000000000 ]---
> ```
> 
> It is based on linux-next (tag next-20260331) and has been tested on
> Mediatek Genio 510-EVK (mt8390) and 1200-EVK (mt8395) boards.
> ---
>  drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> index 8c684756d5fc2524da3a67f67f0fdda894b676fc..d147ec48308110ae8520662e182dc0445447d8d0 100644
> --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> @@ -1202,7 +1202,8 @@ static int mtk_jpeg_release(struct file *file)
>  	struct mtk_jpeg_dev *jpeg = video_drvdata(file);
>  	struct mtk_jpeg_ctx *ctx = mtk_jpeg_file_to_ctx(file);
>  
> -	cancel_work_sync(&ctx->jpeg_work);
> +	if (jpeg->variant->jpeg_worker)
> +		cancel_work_sync(&ctx->jpeg_work);
>  	mutex_lock(&jpeg->lock);
>  	v4l2_m2m_ctx_release(ctx->fh.m2m_ctx);
>  	v4l2_ctrl_handler_free(&ctx->ctrl_hdl);
> 
> ---
> base-commit: e5da3eef8dadab4e98b228725ca8948edd9d601f
> change-id: 20260401-mtk-jpeg-release-issue-d8921970a250
> 
> Best regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mediatek/attachments/20260408/a8b8c4ca/attachment.sig>