Hi Christian, On Mon, Oct 19, 2026 at 04:48:13PM +0100, Christian König wrote: > > What the drivers do more likely is that they use the vmap interface to access > the DMA-buf with the CPU inside the kernel. Correct? >
Yes. UVC and the tested vivid vb2-vmalloc path write the imported DMA-BUF through a kernel vmap. Userspace mmaps the DMA-BUF and brackets each read with DMA_BUF_IOCTL_SYNC. > In this case dma_buf_begin_cpu_access() and dma_buf_end_cpu_access() should > be called to properly frame that access. > > That seems to be added in patch #2, but I absolutely can't judge if that is > correct or not since at the same time you speak about userptr access and the > code really looks a bit like spaghetti. USERPTR is not part of the CPU-access bracketing. The cover letter mentions it only as a regression test. An earlier version changed q->dma_dir to DMA_BIDIRECTIONAL and made read-only output USERPTR fail PREPARE_BUF with EFAULT. Patch 2 leaves q->dma_dir unchanged and passes DMA_BIDIRECTIONAL only to attach_dmabuf() for imported DMA-BUFs. Thanks, Karl
