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

[Seifelden Abdelmonem]

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.

Regards,

Seifelden