mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


  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®