From: Seifelden Abdelmonem <saif.elden.hatim@gmail.com>
To: Bin Du <bin.du@amd.com>, Nirujogi Pratap <pratap.nirujogi@amd.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Sultan Alsawaf <sultan@kerneltoast.com>,
Svetoslav Stoilov <Svetoslav.Stoilov@amd.com>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
Seifelden Abdelmonem <saif.elden.hatim@gmail.com>
Subject: [PATCH 1/2] media: amd: isp4: hold buf_list_lock while sending buffers at stream start
Date: Mon, 26 Oct 2026 21:24:41 +0300 [thread overview]
Message-ID: <20261026182442.229869-2-saif.elden.hatim@gmail.com> (raw)
In-Reply-To: <20261026182442.229869-1-saif.elden.hatim@gmail.com>
isp4vid_qops_start_streaming() walks isp_vdev->buf_list without
buf_list_lock and passes each buffer to isp4sd_ioc_send_img_buf().
Every other access to buf_list holds that lock.
vb2 serialises the walk against buf_queue(), but not against the
firmware response thread. Once ISP4SD_MIN_BUF_CNT_BEF_START_STREAM
buffers have been sent, isp4sd_ioc_send_img_buf() also sends
START_STREAM, so the firmware can complete buffers while the walk is
still running. isp4vid_handle_frame_done() then list_del()s the
completed buffer from buf_list. If that buffer is the current entry of
the walk, list_for_each_entry() follows the poisoned next pointer:
Oops: general protection fault, maybe for address 0xffff8e6944d97060
RIP: 0010:isp4if_alloc_buffer_node+0x37/0x50 [amd_isp4_capture]
RBX: dead0000000000b8 ... RSI: dead0000000000b8
Call Trace:
isp4sd_ioc_send_img_buf
isp4vid_qops_start_streaming
vb2_start_streaming
vb2_core_streamon
The oopsing task holds the queue lock, so the video device can no
longer be closed and the module cannot be unloaded until reboot.
This was hit on a board that is not supported upstream yet, with an
out-of-tree change that made one isp4sd_ioc_send_img_buf() call take
over a second. With the stock driver the window is much shorter, but
the list is still modified concurrently without the lock.
Hold buf_list_lock across the walk. This adds the lock order
buf_list_lock -> ops_mutex. No path takes them in the reverse order:
isp4vid_handle_frame_done() runs in the response thread without
ops_mutex. isp4sd_ioc_send_img_buf() only queues commands and does not
wait for a firmware response, so the response thread is at most
delayed until the initial buffers have been sent.
Fixes: 2ccf48af2270 ("media: platform: amd: isp4 video node and buffers handling added")
Signed-off-by: Seifelden Abdelmonem <saif.elden.hatim@gmail.com>
---
Testing and AI use: see the cover letter.
drivers/media/platform/amd/isp4/isp4_video.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/amd/isp4/isp4_video.c b/drivers/media/platform/amd/isp4/isp4_video.c
index 856a2a0b4..58ea8d6ac 100644
--- a/drivers/media/platform/amd/isp4/isp4_video.c
+++ b/drivers/media/platform/amd/isp4/isp4_video.c
@@ -567,9 +567,11 @@ static int isp4vid_qops_start_streaming(struct vb2_queue *vq,
}
}
- list_for_each_entry(isp4vid_buf, &isp_vdev->buf_list, list)
- isp4sd_ioc_send_img_buf(isp_vdev->isp_sdev,
- &isp4vid_buf->img_buf);
+ scoped_guard(mutex, &isp_vdev->buf_list_lock) {
+ list_for_each_entry(isp4vid_buf, &isp_vdev->buf_list, list)
+ isp4sd_ioc_send_img_buf(isp_vdev->isp_sdev,
+ &isp4vid_buf->img_buf);
+ }
isp_vdev->stream_started = true;
--
2.56.0
next prev parent reply other threads:[~2026-10-26 18:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 18:24 [PATCH 0/2] media: amd: isp4: two fixes found on the ROG Flow Z13 Seifelden Abdelmonem
2026-10-26 18:24 ` Seifelden Abdelmonem [this message]
2026-10-26 18:24 ` [PATCH 2/2] media: amd: isp4: return capture buffers with V4L2_FIELD_NONE Seifelden Abdelmonem
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=20261026182442.229869-2-saif.elden.hatim@gmail.com \
--to=saif.elden.hatim@gmail.com \
--cc=Svetoslav.Stoilov@amd.com \
--cc=bin.du@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=pratap.nirujogi@amd.com \
--cc=sakari.ailus@linux.intel.com \
--cc=sultan@kerneltoast.com \
/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
all inboxes | Powered by JetHome®