深入 Linux DMA-BUF（四）：精讲精问——20 道题吃透三篇核心

用 20 道问答，检验你是否真的掌握了 DMA-BUF 的架构、Cache、Fence 与 Heaps

本文是《深入 Linux DMA-BUF》系列第四篇，也是一篇「主动回忆」练习。前三篇分别讲了整体架构与生命周期、CPU 访问与 Cache 一致性、Fence 同步与 DMA-BUF Heaps。本篇不引入新知识点，而是通过 20 道精选问题，帮你发现认知盲区、固化核心结论。每道题都给出了答案和关键结论，建议先自己作答，再对照。

你读过很多技术文章，每次读完都感觉「懂了」——每段话读起来顺畅，每个概念点头认同，合上文章却说不清楚 dma_buf_fd() 到底有没有增加引用计数，也不确定 Cache Invalidate 和 Cache Flush 应该用在哪个方向。

这种「伪掌握」在系统底层领域尤其危险。DMA-BUF 的坑几乎都藏在「以为懂了但其实没懂」的细节里——attach 不改 f_count、volatile 对 DMA 无效、Fence 回调不能 sleep……每一条单独看都是显而易见的，但在工程现场往往就是会踩。

前三篇把 DMA-BUF 的三个核心维度讲完了：

本文不引入新内容，只做一件事：用 20 道问题把这套体系从头到尾拷问一遍。建议先自己作答，再对照答案，找到你真正的短板。

DMA-BUF 三维知识体系全景

先看一张整体架构图，把握三篇知识的全貌：

图中按三个维度组织：空间维度（左中，零拷贝共享）、CPU 访问维度（右上，Cache 一致性）、时间维度（右下，多硬件时序）。每个维度内的组件关系和核心公式一目了然。

第一篇：架构、生命周期与 f_count

Q1：dma-buf「不生产数据、不搬运数据」——那它到底做了什么？

答：

dma-buf 做的是建立秩序，具体是四件事：

1. 把物理内存打包成带 fd 的对象，作为跨进程通行证
2. 为每个 Importer 设备单独建立 IOVA 映射（调用 IOMMU），返回该设备专属的 sg_table
3. 通过 Fence + dma_resv 协调多硬件的并发访问时序
4. 用 f_count 引用计数确保没有人用时才真正释放物理内存

核心结论：dma-buf 是「物流管理中心」，不碰货物本身，只管调度秩序。

Q2：CPU 访问内存和 DMA 访问内存，最本质的区别是什么？

答：

核心结论：「搬进物理内存」和「映射到 VMA」是两回事。数据在物理内存里，CPU 可以选择完全不映射、不参与——零拷贝的本质就在这里。

Q3：GPU 拿到了 dma-buf 引用，为什么不能直接用物理地址做 DMA？

答：

两个原因：

① IOMMU 隔离：硬件 DMA 控制器接在 IOMMU 后面，它只认 IOVA，不认物理地址。直接用物理地址，IOMMU 查不到映射，触发 fault。

② 每个设备的 IOVA 空间独立：同一块物理内存，GPU 和 NPU 的 IOVA 是不同的值，不能共用一张映射表。dma-buf 通过 dma_buf_map_attachment() 为每个设备单独走 IOMMU 建立映射，返回该设备专属的 sg_table。

核心结论：IOMMU 的存在让物理地址对设备不可见，sg_table 是设备能看懂的「IOVA 路线图」。

Q4：Camera 写完数据后，如何通知 GPU「可以读了」？Fence 挂在哪个对象上？

答：

Fence 挂在 dma_resv（Reservation Object）上，而 dma_resv 是 dma_buf 结构体的 resv 字段——即每个 buffer 自带一个。

通知流程：

Camera 驱动写完数据
    → dma_fence_signal(cam_fence)
        → 原子设置 SIGNALED 标志
        → 遍历执行回调：唤醒正在 dma_resv_wait_timeout() 等待的 GPU 驱动
            → GPU DMA 启动 ✅

核心结论：Fence 是 buffer 的附属物（挂在 dma_resv 上），不是独立的全局对象。

Q5：f_count 变化填空

操作                    f_count    说明
─────────────────────────────────────────────────
dma_buf_export()    →   ?
dma_buf_fd()        →   ?
dma_buf_get(fd)     →   ?
dma_buf_attach(dev) →   ?
dma_buf_detach(dev) →   ?
dma_buf_put()       →   ?

答：

操作                    f_count    说明
─────────────────────────────────────────────────
dma_buf_export()    →   1    alloc_file_pseudo 创建文件，初始引用
dma_buf_fd()        →   1    fd_install 不调用 get_file，不增引用 ⚠️
dma_buf_get(fd)     →   2    fget → get_file，+1
dma_buf_attach(dev) →   2    只建设备关联，不持有 file 引用 ⚠️
dma_buf_detach(dev) →   2    同上，不变 ⚠️
dma_buf_put()       →   1    fput，-1

核心结论：dma_buf_fd() 和 attach/detach 都不改变 f_count，这是最常见的认知错误。只有 get_file / fput 系列才改变引用计数。

Q6：父进程 fork() 后，子进程自动持有父进程的 dmabuf fd，f_count 会变化吗？

答：

会，f_count++。

fork() 时内核复制整个 fd 表，对每个打开的 file 调用 get_file()，路径是 VFS 的 dup_fd() → get_file()，与 dma_buf_fd() 完全无关。

核心结论：如果只统计 dma_buf_fd() 的调用次数来估算 fd 总数，会低估实际值，因为 fork/dup 不走这个路径。

Q7：f_count = 5，但 /proc/[pid]/fd 只扫到 2 个持有者，其余 3 个引用来自哪里？

答：

f_count 的构成公式：

f_count = 1（export 初始）
        + N（用户态 fd，含 dup/fork）
        + M（内核侧 get_dma_buf / dma_buf_get）

多出来的 3 个来自内核侧：驱动内部调用了 get_dma_buf() 或 dma_buf_get()，这些引用不体现在任何进程的 /proc/[pid]/fd 里。

典型场景：GPU 驱动把 dmabuf 指针存进提交的 job 对象，job 执行期间持有内核侧引用。

核心结论：通过 /proc 扫到的只是冰山一角，内核侧引用完全不可见，只能通过 f_count 本身减去已知引用来反推。

Q8：dma_buf_fd() 被调用两次会产生几个 fd？close 时 f_count 如何变化？

答：

产生 2 个独立 fd，各自有独立的 fd 号。

每次 dma_buf_fd() 调用 fd_install() 时，file 的引用已经在创建时算进去了（alloc_file_pseudo 在 export 时给了初始引用，fd_install 把这个引用「转移」给了 fd 表）。所以：

• close 第一个 fd → f_count--
• close 第二个 fd → f_count--

两个 fd 完全独立，关闭一个不影响另一个继续使用 buffer。

核心结论：多次调用 dma_buf_fd() 是合法的，但每个 fd 都需要独立 close，忘了 close 会泄漏。

Q9：如何用 shell 找出哪个 exporter 分配的 dma-buf 总量最大？

答：

for d in /sys/kernel/dmabuf/buffers/*/; do
    name=$(cat "$d/exporter_name")
    size=$(cat "$d/size")
    echo "$name $size"
done | awk '{a[$1]+=$2} END {for(k in a) print a[k], k}' \
     | sort -rn \
     | head -10

按 exporter 名分组求和，降序排列，即可找到内存占用最大的驱动。

核心结论：sysfs 统计只需 exporter_name + size 两个节点，shell 一行可以完成分析。

第二篇：CPU 访问与 Cache 一致性

Q10：Exporter 只实现了三个必须回调，用户态调用 mmap(fd) 会发生什么？

答：

失败。mmap 对应 dma_buf_ops->mmap，这是可选回调。若未实现，内核在 dma_buf_mmap_internal()（drivers/dma-buf/dma-buf.c）里检查到该函数指针为 NULL，返回 -EINVAL，用户态 mmap() 返回 MAP_FAILED。

buffer 本身不受影响，硬件 DMA 路径（map_dma_buf）照常工作——mmap 只影响 CPU 访问路径。

核心结论：mmap 可选，不实现不代表 buffer 不能用，只代表 CPU 无法直接读写。

Q11：GPU 写完数据，CPU 准备读。begin_cpu_access(DMA_FROM_DEVICE) 做的是 Cache Invalidate 还是 Cache Flush？两者区别是什么？搞反了会发生什么？

答：

做的是 Cache Invalidate（无效化）。

DMA_FROM_DEVICE 的语义：设备（GPU）已把最新数据写进 DDR，CPU 准备来读。CPU Cache 里可能还缓存着旧内容——需要 Invalidate 把旧副本清掉，强制 CPU 下次读时从 DDR 取最新值。

搞反了（用 Flush 代替 Invalidate）：CPU 会把 Cache 里的旧数据写回 DDR，覆盖 GPU 刚写入的新数据，导致数据被污染——画面花屏、数据错乱，且偶现难复现。

核心结论：读方向（CPU 读 Device 写）= Invalidate；写方向（CPU 写供 Device 读）= Flush。记错方向是高频踩坑点。

Q12：用户态通过 mmap 读取 dma-buf，省略了 DMA_BUF_IOCTL_SYNC，会怎样？

答：

数据可能不一致。省略 DMA_BUF_SYNC_START（对应 begin_cpu_access/Cache Invalidate），CPU 读到的可能是 Cache 中的旧数据；省略 DMA_BUF_SYNC_END（对应 end_cpu_access/Cache Flush），CPU 写的数据可能没有刷回 DDR，设备 DMA 读到的是旧内容。

症状特征：偶现画面花屏或数据错乱，重启或重跑就好，因为 Cache 状态每次启动都不同，导致 bug 难以稳定复现。

核心结论：DMA_BUF_IOCTL_SYNC 是用户态 CPU 访问 dma-buf 的强制配套，省略它是最高频的踩坑点。

Q13：my_map_dma_buf 里 sg_alloc_table() 和 dma_map_sgtable() 各自做了什么？只调用前者不调用后者会怎样？

答：

sg_alloc_table() + sg_set_buf()：在内核虚拟地址层面构造散列表，描述「这块内存由哪些物理页组成」。此时只有 CPU 认识这张表，硬件 DMA 不认识。

dma_map_sgtable(attach->dev, sgt, dir, 0)：让 IOMMU 为目标设备建立 IOVA 映射，把 sg_table 中的地址翻译成该设备的 IOVA，写入 IOMMU 页表。完成后硬件 DMA 才能按这张表访问内存。

只调用前者：设备 DMA 控制器拿到的地址在其 IOVA 空间里查不到映射，触发 IOMMU fault，轻则 DMA 数据乱，重则系统崩溃。

核心结论：sg_alloc_table 建「CPU 地图」，dma_map_sgtable 建「设备 IOVA 地图」，两步缺一不可。

第三篇：Fence 同步与 DMA-BUF Heaps

Q14：零拷贝已经实现了，为什么还需要 Fence？用 volatile bool camera_done 轮询有什么本质问题？

答：

volatile bool 方案有三个致命缺陷：

① CPU Cache 与 DMA 不同步：volatile 只保证 CPU 不优化掉读操作，但 DMA 是硬件直接写 DDR，CPU Cache 可能完全没刷新。GPU 轮询到 camera_done == true 时，buffer 数据可能还在 Camera 的 write buffer 里尚未到达 DDR。

② GPU 无法「轮询」：GPU 是独立硬件引擎，不会跑 C 代码检查标志位。让 GPU 等待，必须用 GPU 硬件控制器能理解的机制——Fence signal 写入 GPU 的 timeline 寄存器，硬件才能感知并暂停。

③ 无内存屏障保证：标志位的写和 buffer 写完之间没有 memory barrier，CPU/编译器乱序可能导致 camera_done = true 先于实际写操作提交。

核心结论：Fence 解决的是硬件信令问题，不是软件线程同步问题。volatile 对硬件 DMA 毫无意义。

Q15：dma_fence_add_callback() 注册的回调里，能申请 mutex_lock() 吗？为什么？

答：

不能。

dma_fence_signal() 执行回调时，可能运行在中断上下文或持锁状态下。中断上下文禁止睡眠，而 mutex_lock() 在锁竞争时会调用 schedule() 睡眠等待——这会直接触发内核 BUG: scheduling while atomic，系统崩溃。

回调函数的规则：必须是原子操作，不能 sleep，不能申请任何可能阻塞的锁。

需要做复杂工作时，正确做法是在回调里 schedule_work()，把任务扔到工作队列，在进程上下文里执行。

核心结论：Fence 回调 = 中断上下文规则。任何在普通函数里合法的阻塞操作，在这里都是定时炸弹。

Q16：Camera 写 buffer（WRITE fence），GPU_A 和 GPU_B 都在读（READ fence）。Camera 来写新一帧，需要等 GPU_B 吗？用什么 usage 来等？

答：

需要等。Camera 是新一轮写操作，写之前必须确认没有任何正在进行的读：

dma_resv_wait_timeout(dmabuf->resv,
                      DMA_RESV_USAGE_READ,  // 等所有 READ fence
                      true, timeout);

DMA_RESV_USAGE_READ 的语义是「等待所有读方完成」。GPU_A 已读完（READ fence 已 signal），GPU_B 还没读完（READ fence 未 signal）——Camera 会阻塞到 GPU_B 的 READ fence signal 后才开始写新帧。

dma_resv 的读写语义：写等所有读（USAGE_READ），读等写（USAGE_WRITE），读和读之间不互斥。

核心结论：写操作是独占的，必须等所有现存读操作完成。这是防止写覆盖正在读的内容。

Q17：没有 CCI 的 SoC，Camera → CPU AI 推理 → GPU 渲染 pipeline，AI 推理的 buffer 选 system 还是 system-uncached？选错了会有什么具体后果？

答：

选 system-uncached。

原因：没有 CCI（Cache Coherent Interconnect），CPU Cache 和 GPU/Camera 的 DMA 访问不自动一致。

选 system（有 Cache）时：

• AI 推理完把结果写进 CPU Cache，但 GPU 发起 DMA 读时走 DDR，拿到的是推理前的旧数据 → GPU 渲染错误帧
• 反方向：GPU 写进 DDR 的数据，CPU 读到的可能还是 Cache 里的旧副本

每次交接需要手动 DMA_BUF_IOCTL_SYNC，代价高且容易漏。

选 system-uncached：CPU 每次访问直接走 DDR，没有 Cache，所有设备看到的内存状态始终一致。代价是 CPU 访问速度下降（无 Cache 加速），但对于 AI 推理以顺序读写为主的场景，代价可以接受。

有 CCI 的 SoC：Cache 一致性由硬件保证，选 system 即可，CPU 访问更快。

核心结论：system-uncached 是「用 CPU 速度换 Cache 同步零成本」，在无 CCI + CPU-设备频繁交替访问场景下是正确选择。

补充题：第三篇未考到的知识点

Q18：Compositor 合成多个图层时，为什么用普通 mutex 锁 dma_resv 会死锁？ww_mutex 如何解决？

答：

死锁场景：Compositor 合成一帧需要同时锁定所有图层的 buffer（假设图层 A、B、C）。

线程 1（Compositor）:  lock(A) → 等待 lock(B)...
线程 2（GPU 驱动）:    lock(B) → 等待 lock(A)...
→ 死锁 ❌

两个线程各持一把锁，互等对方，普通 mutex 无法自动解除。

ww_mutex（Wound-Wait Mutex）解法：

每个加锁操作携带一个全局唯一的 ww_acquire_ctx，ctx 里有一个时间戳（ticket）。当发生锁竞争时：

规则：「年轻让路给年长」
- 持锁者比等待者年长（ticket 更小）→ 等待者「受伤」(Wound)，主动回退，释放已持有的所有锁，重新排队
- 持锁者比等待者年轻 → 持锁者等待（Wait）

回退后重试，最终年长的线程先拿到所有锁，不会死锁。

实际使用：
dma_resv_lock(resv_A, &ctx);   // ctx 带时间戳
dma_resv_lock(resv_B, &ctx);   // 如果竞争，按 ww 规则自动处理
...
dma_resv_unlock_all(&ctx);

核心结论：ww_mutex 解决的是「多线程同时锁多个对象」的经典死锁问题，是 GPU/Compositor 场景的专用武器。它的代价是加锁失败时需要重试，但正确性得到保证。

Q19：dma_fence 有 context 和 seqno 两个字段，为什么不用一个全局唯一 ID？这两个字段分别代表什么？

答：

context（timeline 上下文 ID）：标识「哪条独立的工作流水线」。每个 GPU queue、DMA channel、渲染引擎都有唯一的 context，由 dma_fence_context_alloc() 分配。

seqno（序列号）：标识「这条流水线上的第几号任务」，同一 context 内单调递增。

为什么需要两个字段而不是一个全局唯一 ID？

关键是利用「同一 context 内 seqno 单调递增」这个性质做快速优化：

同一 context 上：
seqno=5 已完成 → seqno=1,2,3,4 必然也已完成

结论：等待 seqno=3 时，发现 seqno=5 已 signal
      → 直接返回「已完成」，不用再等待
      → O(1) 判断，无需遍历

如果用单一全局 ID，就无法利用这个有序性，每个 Fence 都要独立追踪，失去了批量优化的机会。

这个机制在 dma_fence_is_later() 中实现：

/* 判断 fence a 是否比 fence b 更晚完成 */
static inline bool dma_fence_is_later(struct dma_fence *a, struct dma_fence *b)
{
    /* 只有同一 context 才能比较 seqno */
    if (WARN_ON(a->context != b->context))
        return false;
    return (int64_t)(a->seqno - b->seqno) > 0;
}

核心结论：context 标识「谁在干活」，seqno 标识「干到第几步」。两者配合，让同一流水线上的 Fence 可以用 seqno 大小关系快速推断完成状态，避免逐一等待。

Q20：用户态 Vulkan/OpenGL ES 如何感知 GPU Fence 完成？sync_file 是什么？它和 dma_fence 是什么关系？

答：

dma_fence 是内核对象，用户态无法直接访问。sync_file 是把一个或多个 dma_fence 封装成 fd 的机制，让内核 Fence 能在用户态流转。

关系：

内核侧                      用户侧
  │                           │
dma_fence（GPU完成信号）       │
  │                           │
  └─ sync_file_create()  →  fd（可传给用户态）
         │                    │
         │   poll(fd) / ioctl  │
         │ ◄──────────────────│
         │   → 等待 dma_fence signal
         │                    │
  dma_fence_signal()          │
         │──────────────────► │ fd 变为可读（poll 返回）

Android Compositor 的典型用法：

GPU 驱动渲染完一帧
    │
    ├─ 创建 dma_fence（GPU timeline fence）
    ├─ sync_file_create(fence) → release_fence_fd
    └─ 通过 ANativeWindow queue buffer 把 fd 传给 SurfaceFlinger

SurfaceFlinger（Compositor）
    ├─ 收到 release_fence_fd
    ├─ sync_wait(release_fence_fd, timeout) 等 GPU 渲染完
    └─ Display DMA 扫描输出 ✅

为什么不直接用 dma_fence_wait()：SurfaceFlinger 是用户态进程，不能调用内核函数。sync_file 是「Fence 的用户态代理」，通过标准 fd + poll 接口暴露 Fence 状态给用户空间。

下面这张时序图完整展示了 Camera 写帧 → GPU 渲染 → SurfaceFlinger 合成的完整 Fence 流转过程：

核心结论：sync_file = dma_fence 的用户态信使。内核用 dma_fence 协调硬件，用户态用 sync_file fd 感知完成状态，两者共同构成 Android 图形管线的同步体系。

总结：20 道题覆盖的核心认知

三篇的核心线索：dma-buf 体系的三个维度——空间（fd + sg_table 零拷贝共享）、时间（Fence + dma_resv 多硬件时序）、来源（DMA-BUF Heaps 统一分配）——现在都有了答案。而 CPU 访问时的 Cache 一致性，是这套体系里唯一需要工程师手动介入的部分，也是最高频的踩坑来源。