[PATCH liburing] examples/zcrx: don't forget to sync dmabuf

[PATCH liburing] examples/zcrx: don't forget to sync dmabuf

[Pavel Begunkov]

dma-bufs are not always coherent and we need to sync it before
accessing. Use proper dma-buf API for that.

Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
---
 examples/zcrx.c | 40 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/examples/zcrx.c b/examples/zcrx.c
index b55b07ce..47036a33 100644
--- a/examples/zcrx.c
+++ b/examples/zcrx.c
@@ -39,6 +39,7 @@
 
 #include <linux/memfd.h>
 #include <linux/udmabuf.h>
+#include <linux/dma-buf.h>
 
 #include "liburing.h"
 #include "helpers.h"
@@ -103,12 +104,46 @@ static unsigned long area_token;
 static bool stop;
 static __u32 zcrx_id;
 
-static int dmabuf_fd;
+static int dmabuf_fd = -1;
 static int memfd;
 
 static int listen_fd;
 static int target_cpu = -1;
 
+static void dma_buf_begin_cpu_access(void)
+{
+	struct dma_buf_sync sync = {
+		.flags = DMA_BUF_SYNC_START | DMA_BUF_SYNC_RW,
+	};
+	int ret;
+
+	if (dmabuf_fd < 0)
+		return;
+
+	ret = ioctl(dmabuf_fd, DMA_BUF_IOCTL_SYNC, &sync);
+	if (ret) {
+		fprintf(stderr, "sync failed %i\n", errno);
+		exit(1);
+	}
+}
+
+static void dma_buf_end_cpu_access(void)
+{
+	struct dma_buf_sync sync = {
+		.flags = DMA_BUF_SYNC_END | DMA_BUF_SYNC_RW,
+	};
+	int ret;
+
+	if (dmabuf_fd < 0)
+		return;
+
+	ret = ioctl(dmabuf_fd, DMA_BUF_IOCTL_SYNC, &sync);
+	if (ret) {
+		fprintf(stderr, "sync failed %i\n", errno);
+		exit(1);
+	}
+}
+
 static int get_sock_cpu(int sockfd)
 {
 	int cpu;
@@ -373,6 +408,8 @@ static void verify_data(__u8 *data, size_t size, unsigned long seq)
 	if (!cfg_verify_data)
 		return;
 
+	dma_buf_begin_cpu_access();
+
 	for (i = 0; i < size; i++) {
 		__u8 expected = (__u8)'a' + (seq + i) % 26;
 		__u8 v = data[i];
@@ -382,6 +419,7 @@ static void verify_data(__u8 *data, size_t size, unsigned long seq)
 				(unsigned)i, expected, v, (int)expected - v,
 				seq, seq + i);
 	}
+	dma_buf_end_cpu_access();
 }
 
 static unsigned rq_nr_queued(struct io_uring_zcrx_rq *rq)
-- 
2.54.0

Re: [PATCH liburing] examples/zcrx: don't forget to sync dmabuf

[Jens Axboe]

On 10/16/26 10:25 AM, Pavel Begunkov wrote:
> dma-bufs are not always coherent and we need to sync it before
> accessing. Use proper dma-buf API for that.

Can we get a Fixes tag for this please? Other fixes from today
lacked that as well, please always add fixes tags.

-- 
Jens Axboe

Re: [PATCH liburing] examples/zcrx: don't forget to sync dmabuf

[Pavel Begunkov]

On 10/16/26 17:29, Jens Axboe wrote:
> On 10/16/26 10:25 AM, Pavel Begunkov wrote:
>> dma-bufs are not always coherent and we need to sync it before
>> accessing. Use proper dma-buf API for that.
> 
> Can we get a Fixes tag for this please? Other fixes from today
> lacked that as well, please always add fixes tags.

There was no "fixes" today. I didn't know you care about
liburing fixes tags either, but if you want to put one:

Fixes: 93d3a7a70b4a6 ("examples/zcrx: udmabuf backed areas")

-- 
Pavel Begunkov

Re: [PATCH liburing] examples/zcrx: don't forget to sync dmabuf

[Jens Axboe]

On 10/16/26 10:36 AM, Pavel Begunkov wrote:
> On 10/16/26 17:29, Jens Axboe wrote:
>> On 10/16/26 10:25 AM, Pavel Begunkov wrote:
>>> dma-bufs are not always coherent and we need to sync it before
>>> accessing. Use proper dma-buf API for that.
>>
>> Can we get a Fixes tag for this please? Other fixes from today
>> lacked that as well, please always add fixes tags.
> 
> There was no "fixes" today.

Sure let's argue that, I merged 4 fixes from you this morning. None of
them had Fixes tags.

> liburing fixes tags either, but if you want to put one:
> 
> Fixes: 93d3a7a70b4a6 ("examples/zcrx: udmabuf backed areas")

Because it's always nice to have the reference, even if there are
no stable trees or anything like that on the liburing side.

-- 
Jens Axboe

Re: [PATCH liburing] examples/zcrx: don't forget to sync dmabuf

[Jens Axboe]

On Fri, 16 Oct 2026 17:25:05 +0100, Pavel Begunkov wrote:
> dma-bufs are not always coherent and we need to sync it before
> accessing. Use proper dma-buf API for that.

Applied, thanks!

[1/1] examples/zcrx: don't forget to sync dmabuf
      commit: efa5f5efbeef6967d0a69e3b2c620650e76f4624

Best regards,
-- 
Jens Axboe

Re: [PATCH liburing] examples/zcrx: don't forget to sync dmabuf

[Pavel Begunkov]

On 10/16/26 17:38, Jens Axboe wrote:
> On 10/16/26 10:36 AM, Pavel Begunkov wrote:
>> On 10/16/26 17:29, Jens Axboe wrote:
>>> On 10/16/26 10:25 AM, Pavel Begunkov wrote:
>>>> dma-bufs are not always coherent and we need to sync it before
>>>> accessing. Use proper dma-buf API for that.
>>>
>>> Can we get a Fixes tag for this please? Other fixes from today
>>> lacked that as well, please always add fixes tags.
>>
>> There was no "fixes" today.
> 
> Sure let's argue that, I merged 4 fixes from you this morning. None of
> them had Fixes tags.

There is nothing to argue about, I doubt anyone would call a
tabulation change or adding a kerneldoc "a fix".

>> liburing fixes tags either, but if you want to put one:
>>
>> Fixes: 93d3a7a70b4a6 ("examples/zcrx: udmabuf backed areas")
> 
> Because it's always nice to have the reference, even if there are
> no stable trees or anything like that on the liburing side.

Sure

-- 
Pavel Begunkov

Re: [PATCH liburing] examples/zcrx: don't forget to sync dmabuf

[Jens Axboe]

On 10/16/26 10:47 AM, Pavel Begunkov wrote:
> On 10/16/26 17:38, Jens Axboe wrote:
>> On 10/16/26 10:36 AM, Pavel Begunkov wrote:
>>> On 10/16/26 17:29, Jens Axboe wrote:
>>>> On 10/16/26 10:25 AM, Pavel Begunkov wrote:
>>>>> dma-bufs are not always coherent and we need to sync it before
>>>>> accessing. Use proper dma-buf API for that.
>>>>
>>>> Can we get a Fixes tag for this please? Other fixes from today
>>>> lacked that as well, please always add fixes tags.
>>>
>>> There was no "fixes" today.
>>
>> Sure let's argue that, I merged 4 fixes from you this morning. None of
>> them had Fixes tags.
> 
> There is nothing to argue about, I doubt anyone would call a
> tabulation change or adding a kerneldoc "a fix".

But we're talking about it, now another round... And justifying it. The
way I see it, anything that fixes something in a previous patch is, by
definition, a fix for that patch and should be labeled as such. That's
usually not something that people question. It doesn't need to fix
something that's functionally broken to be labeled a fix. For the
latter, if it's broken in a user visible way, we'd add stable to that
patch as well. Or just send it manually too, if it's missing from the
patch. That's the definition I use as the maintainer of those areas, and
that's why I ask for them.

-- 
Jens Axboe