4. 内存重排序问题：编译器重排序与CPU乱序执行对DMA描述符的影响

在DMA描述符同步中，内存重排序是导致数据不一致的最隐蔽原因之一。即使驱动代码在逻辑上正确，编译器或CPU对内存访问顺序的重新排列，也可能让描述符的所有权标志位与数据载荷的更新顺序颠倒，导致硬件读取到不完整的描述符。

4.1 内存重排序的两大来源

4.2 编译器重排序对DMA描述符的影响

考虑以下典型的描述符提交代码（未加屏障）：

/* 驱动代码：提交一个TX描述符 */
desc->buf_addr   = cpu_to_le32(dma_addr);   // 写1：数据缓冲区地址
desc->buf_len    = cpu_to_le32(pkt_len);     // 写2：数据长度
desc->flags      = cpu_to_le32(OWN_BIT);     // 写3：所有权标志位（最后写）

编译器在开启优化后，可能将desc->flags的赋值提前到desc->buf_addr之前，因为从编译器视角看，这三个写操作之间没有数据依赖关系。结果：DMA控制器看到OWN_BIT置位后，立即读取buf_addr，但此时buf_addr还是旧值（或未初始化值），导致DMA传输到错误的内存地址。

4.3 CPU乱序执行对DMA描述符的影响

即使编译器生成了正确的顺序，CPU在运行时也可能对写操作进行重排序。ARM架构的弱一致性模型允许写缓冲合并和乱序提交，导致以下问题：

1. 写缓冲延迟：CPU核心将desc->buf_addr写入自己的写缓冲，但尚未刷入主存；此时desc->flags的写操作可能先到达内存总线。
2. 多观察者不一致：DMA控制器作为独立的总线主设备，看到的写顺序与CPU核心看到的顺序不同。
3. Store Buffer合并：CPU可能将多个相邻的写操作合并为一个总线事务，改变中间状态的可见性。

4.4 不同架构的重排序行为对比

4.5 编译器屏障 vs CPU屏障：分工与协作

解决内存重排序需要两层屏障协同工作：

/* 正确的描述符提交模式：双重屏障 */
/* 步骤1：写描述符数据 */
desc->buf_addr = cpu_to_le32(dma_addr);
desc->buf_len  = cpu_to_le32(pkt_len);

/* 步骤2：编译器屏障 + CPU写屏障 */
barrier();          // 阻止编译器重排序
dma_wmb();          // 确保数据写操作在标志位之前被DMA控制器看到

/* 步骤3：写所有权标志位 */
desc->flags = cpu_to_le32(OWN_BIT);

4.6 描述符回收时的读重排序问题

当DMA控制器完成传输并清空所有权标志位后，驱动读取描述符时同样面临重排序风险：

/* 驱动轮询等待DMA完成 */
while (le32_to_cpu(desc->flags) & OWN_BIT) {
    cpu_relax();
}

/* 此时驱动认为DMA已完成，读取结果 */
/* 问题：CPU可能乱序读取desc->status，读到旧值！ */
if (le32_to_cpu(desc->status) & ERROR_BIT) {
    /* 错误处理 */
}

正确的做法是在读取标志位之后、读取数据之前插入读屏障：

/* 正确的描述符回收模式 */
while (le32_to_cpu(desc->flags) & OWN_BIT) {
    cpu_relax();
}

/* 读屏障：确保flags的读取完成后再读取其他字段 */
dma_rmb();

/* 安全读取结果 */
if (le32_to_cpu(desc->status) & ERROR_BIT) {
    /* 错误处理 */
}

4.7 总结：内存重排序的防御策略