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

["Nirujogi, Pratap" <pnirujog@amd.com>]

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@amd.com>
Reviewed-by: Pratap Nirujogi <pratap.nirujogi@amd.com>

Thanks,
Pratap


> Regards,
> 
> Seifelden