Question

我正在建立一个基于配备arm64 CPU的UltraScale + FPGA的数据采集系统。数据通过DMA传输到RAM。驱动程序中的DMA缓冲区保留如下：

virt_buf[i] = dma_zalloc_coherent(&pdev->dev, BUF_SIZE, &phys_buf[i],GFP_KERNEL);

在驱动程序的mmap函数中，以下列方式完成到用户空间的映射：

#ifdef ARCH_HAS_DMA_MMAP_COHERENT
   printk(KERN_INFO "Mapping with dma_map_coherent DMA buffer at phys: %p virt %p\n",phys_buf[off],virt_buf[off]);
   res = dma_mmap_coherent(&my_pdev->dev, vma, virt_buf[off], phys_buf[off],  vsize);
#else
   physical = phys_buf[off];
   res=remap_pfn_range(vma,vma->vm_start, physical >> PAGE_SHIFT , vsize, pgprot_noncached(vma->vm_page_prot));
   printk(KERN_INFO "Mapping with remap_pfn_range DMA buffer at phys: %p virt %p\n",physical,virt_buf[off]);
#endif

在我的UltraScale + CPU上使用remap_pfn_range。在用户空间应用程序中，数据从缓冲区中读取，并且当前立即发送长度限制为MAX_DGRAM（最初等于572）的UDP数据包。

 int i = 0;
 int bleft = nbytes;
 while(i<nbytes) {
    int bts = bleft < MAX_DGRAM ? bleft : MAX_DGRAM;
    if (sendto(fd,&buf[nbuf][i],bts,0, res2->ai_addr,res2->ai_addrlen)==-1) {
       printf("%s",strerror(errno));
       exit(1);
    }
    bleft -= bts;
   i+= bts;
 }

一切都在32位Zynq FPGA上完美运行。但是，在我将其移至64位UltraScale + FPGA之后，经过几百次传输后，我开始收到随机错误。

[  852.703491] Unhandled fault: alignment fault (0x96000021) at 0x0000007f82635584
[  852.710739] Internal error: : 96000021 [#4] SMP
[  852.715235] Modules linked in: axi4s2dmov(O) ksgpio(O)
[  852.720358] CPU: 0 PID: 1870 Comm: a4s2dmov_send Tainted: G      D    O    4.4.0 #3
[  852.728001] Hardware name: ZynqMP ZCU102 RevB (DT)
[  852.732769] task: ffffffc0718ac180 ti: ffffffc0718b8000 task.ti: ffffffc0718b8000
[  852.740248] PC is at __copy_from_user+0x8c/0x180
[  852.744836] LR is at copy_from_iter+0x70/0x24c
[  852.749261] pc : [<ffffffc00039210c>] lr : [<ffffffc0003a36a8>] pstate: 80000145
[  852.756644] sp : ffffffc0718bba40
[  852.759935] x29: ffffffc0718bba40 x28: ffffffc06a4bae00 
[  852.765228] x27: ffffffc0718ac820 x26: 000000000000000c 
[  852.770523] x25: 0000000000000014 x24: 0000000000000000 
[  852.775818] x23: ffffffc0718bbe08 x22: ffffffc0710eba38 
[  852.781112] x21: ffffffc0718bbde8 x20: 000000000000000c 
[  852.786407] x19: 000000000000000c x18: ffffffc000823020 
[  852.791702] x17: 0000000000000000 x16: 0000000000000000 
[  852.796997] x15: 0000000000000000 x14: 00000000c0a85f32 
[  852.802292] x13: 0000000000000000 x12: 0000000000000032 
[  852.807586] x11: 0000000000000014 x10: 0000000000000014 
[  852.812881] x9 : ffffffc0718bbcf8 x8 : 000000000000000c 
[  852.818176] x7 : ffffffc0718bbdf8 x6 : ffffffc0710eba2c 
[  852.823471] x5 : ffffffc0710eba38 x4 : 0000000000000000 
[  852.828766] x3 : 000000000000000c x2 : 000000000000000c 
[  852.834061] x1 : 0000007f82635584 x0 : ffffffc0710eba2c 
[  852.839355] 
[  852.840833] Process a4s2dmov_send (pid: 1870, stack limit = 0xffffffc0718b8020)
[  852.848134] Stack: (0xffffffc0718bba40 to 0xffffffc0718bc000)
[  852.853858] ba40: ffffffc0718bba90 ffffffc0006a1b2c 000000000000000c ffffffc06a9bdb00
[  852.861676] ba60: 00000000000005dc ffffffc071a0d200 0000000000000000 ffffffc0718bbdf8
[  852.869488] ba80: 0000000000000014 ffffffc06a959000 ffffffc0718bbad0 ffffffc0006a2358
[...]
[  853.213212] Call trace:
[  853.215639] [<ffffffc00039210c>] __copy_from_user+0x8c/0x180
[  853.221284] [<ffffffc0006a1b2c>] ip_generic_getfrag+0xa4/0xc4
[  853.227011] [<ffffffc0006a2358>] __ip_append_data.isra.43+0x80c/0xa70
[  853.233434] [<ffffffc0006a3d50>] ip_make_skb+0xc4/0x148
[  853.238642] [<ffffffc0006c9d04>] udp_sendmsg+0x280/0x740
[  853.243937] [<ffffffc0006d38e4>] inet_sendmsg+0x7c/0xbc
[  853.249145] [<ffffffc000651f5c>] sock_sendmsg+0x18/0x2c
[  853.254352] [<ffffffc000654b14>] SyS_sendto+0xb0/0xf0
[  853.259388] [<ffffffc000084470>] el0_svc_naked+0x24/0x28
[  853.264682] Code: a88120c7 a8c12027 a88120c7 36180062 (f8408423) 
[  853.270791] ---[ end trace 30e1cd8e2ccd56c5 ]---
Segmentation fault
root@Xilinx-ZCU102-2016_2:~#

奇怪的是，当我只是从缓冲区读取单词时，它不会导致任何对齐错误。

似乎发送功能不正确地使用 __ copy_from_user 功能，导致未对齐的内存访问。问题是：它是内核错误，还是我做错了什么？

但是，通常，发送数据块不是以8字节边界开始不会触发对齐错误。问题以相对较低的概率发生。我无法找出导致错误的条件。

我通过调整MAX_DGRAM来解决这个问题，因此它是8的倍数。但是我担心，如果mmapped缓冲区中的数据被提交给更复杂的处理，问题可能会重新出现。有些人报告arm64架构中与memcpy函数相关的类似问题（例如[https://bugs.launchpad.net/linux-linaro/+bug/1271649]）。

将相干DMA缓冲区映射到用户空间以避免内存对齐错误的正确方法是什么？

Answer 1

该驱动程序需要更新。 ARCH_HAS_DMA_MMAP_COHERENT已经被PowerPC以外的其他任何东西定义了很长时间，甚至看起来像是一个被遗忘的遗留物。

有一个通用的dma_mmap_coherent()实现since 3.6，因此可以而且应该无条件地使用。当前代码的结果是，由于#ifdef，你总是采用其他路径，然后感谢pgprot_noncached()你最终使缓冲区的用户空间映射强烈排序（设备nGnRnE在AArch64术语中）。这通常是一个坏主意，因为用户空间代码将假设它总是在正常内存上运行（除非明确地设计不使用），并且可以安全地执行诸如未对齐或独占访问之类的事情，这两者都易于在设备类型的内存上严重错误。我甚至都不会问内核将数据从内核缓冲区 ^*的用户空间映射中复制回来会产生什么样的疯狂，但是足以满足说内核 - 通过copy_{to,from,in}_user() - 也假设用户空间地址被映射为普通内存，因此对于未对齐的访问是安全的。坦率地说，我很惊讶这并没有在32位ARM上类似地爆炸，所以我猜你的数据总是至少4字节对齐 - 这也解释了为什么读单词（32-如果只有64位双字访问可能会错位，那么位访问就没问题了。

简而言之，只需使用dma_mmap_coherent()，并摆脱开放编码的差等效。这将为用户空间提供正常的非可缓存映射（或硬件相干设备的可缓存映射），这将按预期工作。假设dma_addr_t是一个物理地址，而且你的驱动程序代码似乎也是如此，它也没有被打破 - 这是另一件可能会碰到并咬你的东西迟早会出现这种情况（ZynqMP有一个系统MMU，所以你可以更新到4.9内核，连接一些Stream ID，将它们添加到DT中，然后以新的令人兴奋的方式观察这个假设。）

_{*虽然我确实发现在某些情况下，从页面的最末端进行复制有时可能会过度读入下一页，如果后续页面碰巧是这样，可能会在不知情的情况下触发设备/强排序映射，导致this patch in 4.5。莱纳斯＆＃39;对此类内存布局的响应为"...and nobody sane actually does that..."}

arm64上的Linux：sendto导致＆＃34;未处理的故障：对齐故障（0x96000021）＆＃34;从mmapped相干DMA缓冲区发送数据时

1 个答案: