From: Bin Du <Bin.Du@amd.com>
To: Seifelden Abdelmonem <saif.elden.hatim@gmail.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, "Chan,
Benjamin (Koon Pan)" <Benjamin.Chan@amd.com>,
"Li, King" <King.Li@amd.com>
Subject: Re: [PATCH 1/2] media: amd: isp4: hold buf_list_lock while sending buffers at stream start
Date: Tue, 27 Oct 2026 16:51:35 +0800 [thread overview]
Message-ID: <8170cb29-05b2-4ef7-84dc-2e89f5b381ce@amd.com> (raw)
In-Reply-To: <20261026182442.229869-2-saif.elden.hatim@gmail.com>
Reviewed-by: Bin Du <bin.du@amd.com>
On 10/27/2026 2:24 AM, Seifelden Abdelmonem wrote:
>
> 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-27 8:52 UTC|newest]
Thread overview: 5+ 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 ` [PATCH 1/2] media: amd: isp4: hold buf_list_lock while sending buffers at stream start Seifelden Abdelmonem
2026-10-27 8:51 ` Bin Du [this message]
2026-10-26 18:24 ` [PATCH 2/2] media: amd: isp4: return capture buffers with V4L2_FIELD_NONE Seifelden Abdelmonem
2026-10-27 8:51 ` Bin Du
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=8170cb29-05b2-4ef7-84dc-2e89f5b381ce@amd.com \
--to=bin.du@amd.com \
--cc=Benjamin.Chan@amd.com \
--cc=King.Li@amd.com \
--cc=Svetoslav.Stoilov@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=pratap.nirujogi@amd.com \
--cc=saif.elden.hatim@gmail.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®