On Mon, Oct 19, 2026 at 09:14:07AM +0200, Karl Mehltretter wrote: > UVC and vivid access imported DMA-BUFs with the CPU without cache > synchronization. On a Pi 400, captured data remained in the CPU cache > while physical RAM was stale. > > Add an opt-in queue flag to bracket CPU access from buf_prepare() through > buf_finish(). The allocator cannot imply CPU use because some vb2-vmalloc > drivers pass buffers to hardware. Patch 1 balances finish operations in > VIDIOC_REMOVE_BUFS so removing prepared buffers closes this interval.
This seems completely wrong. > This follows the per-queue flag proposed here: > https://lists.openwall.net/linux-kernel/2024/06/20/236 > > Based on Linux 7.3. Tests cover the same code on these earlier bases: > > - Pi 400, 7.3-rc4, all four patches: eight 640x480 YUYV frames per run, > imported CMA DMA-BUFs with a DRM device mapping: > > Path Runs Stale frames > UVC, vb2-vmalloc 12 0/96 > vivid, vb2-vmalloc 12 0/96 > vivid, vb2-dma-contig 12 0/96 > > All six lifecycle cases passed with both vivid allocators. Read-only > output USERPTR passed. The test added no warnings or failed CPU-access > callbacks. A control without the DRM mapping found 4/16 stale frames. > > - SAM9X75 (ARMv5), 6.18 backport of all four patches: the baseline > PREPARE_BUF/REMOVE_BUFS imbalance was fixed. USERPTR and six lifecycle > cases passed. All 128 vivid and 96 UVC frames matched RAM, with 100/100 > begin/end calls. The baseline was already coherent. > > - BeagleV Ahead (RISC-V), 7.3-rc7, patches 1, 2 and 4: read-only USERPTR, > six traced lifecycle cases and 60 repeats passed with balanced callbacks > and no kernel diagnostics. A vendor 5.10 backport of patches 2 and 3 > captured 96 UVC frames without stale data, with 100/100 begin/end calls. > Its baseline was already coherent. > > Karl Mehltretter (4): > media: videobuf2: finish prepared buffers in VIDIOC_REMOVE_BUFS > media: videobuf2: add opt-in DMA-BUF CPU access > media: uvcvideo: synchronize imported DMA-BUFs for CPU access > media: vivid: synchronize imported DMA-BUFs for CPU access > > .../media/common/videobuf2/videobuf2-core.c | 96 ++++++++++++++++++- > .../common/videobuf2/videobuf2-dma-contig.c | 5 +- > .../media/common/videobuf2/videobuf2-dma-sg.c | 5 +- > .../common/videobuf2/videobuf2-vmalloc.c | 5 +- > drivers/media/test-drivers/vivid/vivid-core.c | 1 + > drivers/media/usb/uvc/uvc_queue.c | 1 + > include/media/videobuf2-core.h | 12 ++- > 7 files changed, 116 insertions(+), 9 deletions(-) > > > base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222 -- Regards, Laurent Pinchart
