diff options
| author | Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> | 2026-04-01 11:44:15 +0200 |
|---|---|---|
| committer | Hans Verkuil <hverkuil+cisco@kernel.org> | 2026-05-04 08:35:14 +0200 |
| commit | b1845a227fda37b2fe5327df3ca0015d7e290235 (patch) | |
| tree | d49c93a38beef1f48c6ea9bf8d830a5903dc2e20 /include/uapi/linux | |
| parent | 018f2dc3a42098d3b04edd1480adc51d268adb14 (diff) | |
media: mtk-jpeg: cancel workqueue on release for supported platforms only
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")
Cc: stable@vger.kernel.org
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Diffstat (limited to 'include/uapi/linux')
0 files changed, 0 insertions, 0 deletions
