Thread (7 messages) 7 messages, 3 authors, 2025-02-28

Re: [PATCH v3 1/2] media: videobuf2: Fix dmabuf cache sync/flush in dma-contig

From: Tomasz Figa <tfiga@chromium.org>
Date: 2025-02-07 16:22:27
Also in: linux-media, linux-rockchip, lkml, stable

On Tue, Jan 28, 2025 at 9:36 PM Mikhail Rudenko [off-list ref] wrote:
quoted hunk ↗ jump to hunk
When support for V4L2_FLAG_MEMORY_NON_CONSISTENT was removed in
commit 129134e5415d ("media: media/v4l2: remove
V4L2_FLAG_MEMORY_NON_CONSISTENT flag"),
vb2_dc_dmabuf_ops_{begin,end}_cpu_access() functions were made
no-ops. Later, when support for V4L2_MEMORY_FLAG_NON_COHERENT was
introduced in commit c0acf9cfeee0 ("media: videobuf2: handle
V4L2_MEMORY_FLAG_NON_COHERENT flag"), the above functions remained
no-ops, making cache maintenance for non-coherent dmabufs allocated by
dma-contig impossible.

Fix this by reintroducing dma_sync_sgtable_for_{cpu,device} and
{flush,invalidate}_kernel_vmap_range calls to
vb2_dc_dmabuf_ops_{begin,end}_cpu_access() functions for non-coherent
buffers.

Fixes: c0acf9cfeee0 ("media: videobuf2: handle V4L2_MEMORY_FLAG_NON_COHERENT flag")
Cc: stable@vger.kernel.org
Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com>
---
 .../media/common/videobuf2/videobuf2-dma-contig.c  | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index bb0b7fa67b539aa73ad5ccf3c3bc318e26f8a4cb..146d7997a0da5989fb081a6f28ce0641fe726e63 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -427,6 +427,17 @@ static int
 vb2_dc_dmabuf_ops_begin_cpu_access(struct dma_buf *dbuf,
                                   enum dma_data_direction direction)
 {
+       struct vb2_dc_buf *buf = dbuf->priv;
+       struct sg_table *sgt = buf->dma_sgt;
+
+       if (!buf->non_coherent_mem)
+               return 0;
+
+       if (buf->vaddr)
+               invalidate_kernel_vmap_range(buf->vaddr, buf->size);
+
+       dma_sync_sgtable_for_cpu(buf->dev, sgt, buf->dma_dir);
+
        return 0;
 }
@@ -434,6 +445,17 @@ static int
 vb2_dc_dmabuf_ops_end_cpu_access(struct dma_buf *dbuf,
                                 enum dma_data_direction direction)
 {
+       struct vb2_dc_buf *buf = dbuf->priv;
+       struct sg_table *sgt = buf->dma_sgt;
+
+       if (!buf->non_coherent_mem)
+               return 0;
+
+       if (buf->vaddr)
+               flush_kernel_vmap_range(buf->vaddr, buf->size);
+
+       dma_sync_sgtable_for_device(buf->dev, sgt, buf->dma_dir);
+
        return 0;
 }
I took some time (over)thinking the kernel vmap range synchronization,
because these functions can be called both from the kernel space using
respective dma_buf_*() kAPI and also from the user space using the
DMA_BUF_SYNC IOCTLs, so we could in theory have the multiple
invocations racing with each other, but then I realized that we don't
really provide any guarantees for concurrent writes and reads from the
CPU, so I believe this should work fine. Sorry for the delay.

Acked-by: Tomasz Figa <tfiga@chromium.org>

Let me add @Christoph Hellwig and @Robin Murphy just in case I'm wrong
on that, though... Hans, let's give them some time to take a look
before applying this.

Best regards,
Tomasz
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help