From: sashiko-bot@kernel.org
To: "Sven Püschel" <s.pueschel@pengutronix.de>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH 05/17] media: v4l2-mem2mem: support running multiple jobs in parallel
Date: Fri, 05 Jun 2026 22:18:34 +0000 [thread overview]
Message-ID: <20260605221835.335051F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260606-spu-rga3multicore-v1-5-3ec2b15675f7@pengutronix.de>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Lockless list traversal of `job_queue` in `v4l2_m2m_suspend` leads to list corruption and kernel panic.
- [High] Unlocked dereference of `first_ctx` fields in `v4l2_m2m_get_curr_priv` leads to a Use-After-Free.
- [Medium] `v4l2_m2m_get_curr_priv` breaks interrupt mapping for drivers utilizing parallel jobs.
--
commit b3a2fe91efda298e9f5953581aac80b6a8ccdefb
Author: Sven Püschel <s.pueschel@pengutronix.de>
media: v4l2-mem2mem: support running multiple jobs in parallel
Add support for running multiple jobs in parallel for SoCs containing
multiple identical devices. An example is the Rockchip RK3588 SoC,
which contains two identical RGA3 devices.
> diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-core/v4l2-mem2mem.c
> index a65cbb124cfe0..14ac9c85803d1 100644
> --- a/drivers/media/v4l2-core/v4l2-mem2mem.c
> +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
[ ... ]
> @@ -229,14 +235,22 @@ EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove_by_idx);
> void *v4l2_m2m_get_curr_priv(struct v4l2_m2m_dev *m2m_dev)
> {
> unsigned long flags;
> - void *ret = NULL;
> + struct v4l2_m2m_ctx *first_ctx;
>
> spin_lock_irqsave(&m2m_dev->job_spinlock, flags);
> - if (m2m_dev->curr_ctx)
> - ret = m2m_dev->curr_ctx->priv;
> + if (list_empty(&m2m_dev->job_queue)) {
> + spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags);
> + return NULL;
> + }
> +
> + first_ctx = list_first_entry(&m2m_dev->job_queue,
> + struct v4l2_m2m_ctx, queue);
> spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags);
>
> - return ret;
> + if (first_ctx->job_flags & TRANS_RUNNING)
> + return first_ctx->priv;
[Severity: High]
Does this introduce a use-after-free?
The job_spinlock is dropped right before reading first_ctx->job_flags
and first_ctx->priv. If the job is concurrently canceled, it could be
removed from the list and its context freed before these reads occur.
[Severity: Medium]
Will this return the correct context when multiple jobs are running in
parallel?
If max_parallel_jobs > 1, multiple contexts could be marked with
TRANS_RUNNING. Because this function indiscriminately returns the priv
pointer of the first element in the queue, a driver servicing an interrupt
for a newer concurrent job might mistakenly receive the priv of the oldest
running job instead.
> + else
> + return NULL;
> }
> EXPORT_SYMBOL(v4l2_m2m_get_curr_priv);
[ ... ]
> @@ -544,16 +572,19 @@ EXPORT_SYMBOL(v4l2_m2m_buf_done_and_job_finish);
> void v4l2_m2m_suspend(struct v4l2_m2m_dev *m2m_dev)
> {
> unsigned long flags;
> - struct v4l2_m2m_ctx *curr_ctx;
> + struct v4l2_m2m_ctx *ctx;
> + struct v4l2_m2m_ctx *ctx_safe;
>
> spin_lock_irqsave(&m2m_dev->job_spinlock, flags);
> m2m_dev->job_queue_flags |= QUEUE_PAUSED;
> - curr_ctx = m2m_dev->curr_ctx;
> spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags);
>
> - if (curr_ctx)
> - wait_event(curr_ctx->finished,
> - !(curr_ctx->job_flags & TRANS_RUNNING));
> + list_for_each_entry_safe(ctx, ctx_safe, &m2m_dev->job_queue, queue) {
> + if (!(ctx->job_flags & TRANS_RUNNING))
> + break;
> +
> + wait_event(ctx->finished, !(ctx->job_flags & TRANS_RUNNING));
[Severity: High]
Could this result in list corruption?
This loop traverses m2m_dev->job_queue without holding the
m2m_dev->job_spinlock. When wait_event() blocks, a concurrent job
completion could call _v4l2_m2m_job_finish() and remove ctx_safe from the
list via list_del().
When the loop resumes, dereferencing the poisoned ctx_safe pointer would
likely cause a crash.
> + }
> }
> EXPORT_SYMBOL(v4l2_m2m_suspend);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260606-spu-rga3multicore-v1-0-3ec2b15675f7@pengutronix.de?part=5
next prev parent reply other threads:[~2026-06-05 22:18 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 22:06 [PATCH 00/17] media: rockchip: rga: Add multi-core support Sven Püschel
2026-06-05 22:06 ` [PATCH 01/17] media: rockchip: rga: zero cmdbuf in shared code Sven Püschel
2026-06-05 22:20 ` sashiko-bot
2026-06-05 22:06 ` [PATCH 02/17] media: rockchip: rga: add comment about pixel alignment for YUV formats Sven Püschel
2026-06-05 22:06 ` [PATCH 03/17] media: rockchip: rga: move early return into if condition in vidioc_enum_fmt Sven Püschel
2026-06-05 22:06 ` [PATCH 04/17] media: rockchip: rga: removed unused regmap member Sven Püschel
2026-06-05 22:06 ` [PATCH 05/17] media: v4l2-mem2mem: support running multiple jobs in parallel Sven Püschel
2026-06-05 22:18 ` sashiko-bot [this message]
2026-06-05 22:06 ` [PATCH 06/17] media: rockchip: rga: move power handling to device_run Sven Püschel
2026-06-05 22:22 ` sashiko-bot
2026-06-05 22:06 ` [PATCH 07/17] media: rockchip: rga: adjust get_version to return the version Sven Püschel
2026-06-05 22:06 ` [PATCH 08/17] media: rockchip: rga: add rga_core structure Sven Püschel
2026-06-05 22:22 ` sashiko-bot
2026-06-05 22:06 ` [PATCH 09/17] media: rockchip: rga: use components to manage multiple cores Sven Püschel
2026-06-05 22:24 ` sashiko-bot
2026-06-05 22:06 ` [PATCH 10/17] media: rockchip: rga: move rockchip_rga allocation to master probe Sven Püschel
2026-06-05 22:23 ` sashiko-bot
2026-06-05 22:06 ` [PATCH 11/17] media: rockchip: rga: move video device to the master Sven Püschel
2026-06-05 22:21 ` sashiko-bot
2026-06-05 22:06 ` [PATCH 12/17] media: rockchip: rga: move core initialization from bind to probe Sven Püschel
2026-06-05 22:20 ` sashiko-bot
2026-06-05 22:06 ` [PATCH 13/17] media: rockchip: rga: bind all cores to the master Sven Püschel
2026-06-05 22:23 ` sashiko-bot
2026-06-05 22:07 ` [PATCH 14/17] media: rockchip: rga: put all cores into first core iommu domain Sven Püschel
2026-06-05 22:23 ` sashiko-bot
2026-06-05 22:07 ` [PATCH 15/17] media: rockchip: rga: schedule jobs to multiple cores Sven Püschel
2026-06-05 22:25 ` sashiko-bot
2026-06-05 22:07 ` [PATCH 16/17] arm64: dts: rockchip: add rga3 dt nodes to rk3588 Sven Püschel
2026-06-05 22:07 ` [PATCH 17/17] iommu/rockchip: disable fetch dte time limit Sven Püschel
2026-06-05 22:26 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260605221835.335051F00893@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=s.pueschel@pengutronix.de \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox