From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning
Date: Tue, 31 Mar 2026 16:42:34 +1000 [thread overview]
Message-ID: <review-patch1-20260331061657.79983-1-mikhail.v.gavrilov@gmail.com> (raw)
In-Reply-To: <20260331061657.79983-1-mikhail.v.gavrilov@gmail.com>
Patch Review
**Analysis of the change:**
The patch changes two lines in `get_sg_table()` and `put_sg_table()`:
```c
- ret = dma_map_sgtable(dev, sg, direction, 0);
+ ret = dma_map_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC);
```
```c
- dma_unmap_sgtable(dev, sg, direction, 0);
+ dma_unmap_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC);
```
**Correctness:** The change is correct. `get_sg_table()` is called from two places:
1. `map_udmabuf()` (line 186) — the dma-buf `map_dma_buf` op, called by importers. CPU sync at map time is redundant; importers manage their own cache coherency.
2. `begin_cpu_udmabuf()` (line 252) — on the first call, creates the sg table. Subsequent calls use `dma_sync_sgtable_for_cpu()` explicitly (line 258). The initial map doesn't need a sync either, as the pages are freshly mapped.
Similarly, `put_sg_table()` is called from `unmap_udmabuf()` and `release_udmabuf()`, where the CPU sync at unmap time is unnecessary.
**Precedent:** I confirmed that both `drm_gem_map_dma_buf()` (`drm_prime.c:684`) and `amdgpu_dma_buf_map()` (`amdgpu_dma_buf.c:213`) already pass `DMA_ATTR_SKIP_CPU_SYNC`, matching the commit message's claim.
**One minor observation:** The commit message says the flag "suppresses this check in `add_dma_entry()`" — that's slightly imprecise. `DMA_ATTR_SKIP_CPU_SYNC` doesn't directly affect `add_dma_entry()`. Rather, by skipping the CPU cache maintenance, the overlapping mappings become harmless, and the debug infrastructure's concern about cacheline sharing is moot. The warning is still technically possible if both mappings exist simultaneously, but in practice the flag prevents the cache ops that make the overlap dangerous. The actual suppression mechanism may be more nuanced, but the end result is correct — the warning goes away and the behavior is safe.
**Verdict:** Reviewed-by worthy. Clean two-line fix, well-motivated, consistent with how other dma-buf exporters handle this.
---
Generated by Claude Code Patch Reviewer
next prev parent reply other threads:[~2026-03-31 6:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 6:16 [PATCH v2] dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning Mikhail Gavrilov
2026-03-31 6:42 ` Claude Code Review Bot [this message]
2026-03-31 6:42 ` Claude review: " Claude Code Review Bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=review-patch1-20260331061657.79983-1-mikhail.v.gavrilov@gmail.com \
--to=claude-review@example.com \
--cc=dri-devel-reviews@example.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox