Re: [PATCH 1/2] media: amd: isp4: hold buf_list_lock while sending buffers at stream start

[Nirujogi, Pratap]

Hi Seifelden,

On 11/3/2026 10:02 AM, Seifelden Abdelmonem wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> Hello Pratap,
>
> On Mon, Nov 2, 2026, Nirujogi, Pratap wrote:
> > I’m curious about the sequence you are using to reproduce this issue.
> > Would you mind sharing the details of the sequence and steps involved?
>
> Thanks for the review. Nothing special on the userspace side, just a
> plain capture; the exact command from that run was:
>
>    timeout 8s v4l2-ctl -d /dev/video0 \
>        --set-fmt-video=width=1920,height=1080,pixelformat=NV12 \
>        --stream-mmap=4 --stream-count=30 --stream-to=out.nv12 \
>        --stream-poll
>
> The oops happened inside VIDIOC_STREAMON, before the first frame
> reached v4l2-ctl.
>
> What made it hit was an out-of-tree change on my side: the sensor was
> started from inside isp4sd_ioc_send_img_buf(), right after
> START_STREAM was queued with the fourth buffer, and that path had about
> a second of debug sleeps in it. By the time the call returned, the
> firmware had already completed that buffer and
> isp4vid_handle_frame_done() had removed it from buf_list, so the walk
> followed the poisoned next pointer. With the stock driver the window
> is tiny, which fits it never showing up in your tests.
>
> To make it reproducible without the debug sleeps, I put an msleep(500)
> after each isp4sd_ioc_send_img_buf() call in the start_streaming loop:
>
>          list_for_each_entry(isp4vid_buf, &isp_vdev->buf_list, list) {
>                  isp4sd_ioc_send_img_buf(isp_vdev->isp_sdev,
>                                          &isp4vid_buf->img_buf);
>                  msleep(500);
>          }
>
> and ran the same command again (my out-of-tree sensor start was still
> there, the debug sleeps were not):
>
> - unpatched loop: the same oops (GPF in
>    isp4if_alloc_buffer_node+0x37, RBX/RSI dead0000000000b8), 500 ms
>    after the call that queued START_STREAM;
> - with this patch: the capture completes (30 frames), no oops.
>
> I'd expect the same msleep() to reproduce it on the HP ZBook.
Thanks for the detailed explanation, that clarifies why the issue
hasn't shown up with the stock driver in our testing.

I can reproduce the same oops on the HP ZBook with msleep(500) added
after each isp4sd_ioc_send_img_buf() call in the start_streaming loop,
and with this patch applied the capture completes without issues.

Tested-by: Pratap Nirujogi <pratap.nirujogi@xxxxxxx>
Reviewed-by: Pratap Nirujogi <pratap.nirujogi@xxxxxxx>

Thanks,
Pratap


> Regards,
>
> Seifelden