来自DMA的memcpy数据损坏

如何解决来自DMA的memcpy数据损坏

编辑：

不确定这是否是问题，但这是我注意到的一些事情：
rx_skbuffers在两个位置分配：初始化驱动程序后，它将使用GPF_KERNEL调用__netdev_alloc_skb_ip_align，第二次如果rx_skbuff已被释放，则会调用netdev_alloc_skb_ip_align（内部使用GPF_ATOMIC）。

这些skb分配不应该用GPF_DMA调用吗？

================================================ =========================

我正在使用的以太网驱动程序（对于ST MAC 10/100/1000）中的数据损坏有问题。该驱动程序在Allwinner A20（ARM Cortex-A7）上运行。

一些详细信息：

驱动程序拥有一个Rx sk_buffer环（已与__netdev_alloc_skb_ip_align分配）。
使用rx_skbuff[i]->data将每个sk_buffers的数据（dma_map_single）映射到DMA。
映射成功（已通过dma_mapping_error验证）。

问题：

过一会儿（几分钟，几小时，几天……非常随机），由于数据损坏导致内核崩溃。

调试（已编辑）：

深入研究后，我发现有时过一会儿，sk_buffer结构之一被破坏，这可能导致程序执行它不应该做的事情，从而导致内核崩溃。
经过进一步的挖掘，我发现损坏发生在skb_copy_to_linear_data之后（与memcpy相同）。请记住，这种损坏不会在每次调用skb_copy_to_linear_data之后发生，但是当确实发生损坏时，它总是在调用skb_copy_to_linear_data之后发生。
发生损坏时，不会在当前条目（rx_q->rx_skbuff）的rx_q->rx_skbuff[entry]上发生。例如，如果我们在skb_copy_to_linear_data上执行rx_q->rx_skbuff[X]，则损坏的sk_buff结构将是rx_q->rx_skbuff[Y]（其中X不等于Y）。
似乎skb->data的物理地址（已在skb_copy_to_linear_data调用之前分配）具有相同的物理地址rx_q->rx_skbuff[Y]->end。我首先想到的是，驱动程序可能不知道rx_q-> rx_skbuff [Y]已被释放，但是当发生这种冲突时，我看到rx_q-> rx_skbuff [Y]->用户为1。 怎么可能，有什么想法吗？
不确定这是否是问题，但这是我注意到的一些事情：
rx_skbuffers在两个位置分配：初始化驱动程序后，它将使用GPF_KERNEL调用__netdev_alloc_skb_ip_align，第二次如果rx_skbuff已被释放，则会调用netdev_alloc_skb_ip_align（内部使用GPF_ATOMIC）。 是否应使用GPF_DMA调用这些skb分配？

代码：

这是发生损坏的代码的一部分。
驱动程序的完整代码来自linux内核主线4.19，可以在here中找到。我只在这里粘贴了3451-3474行之间的部分。
有人在这里发现有关使用DMA-API的错误行为吗？

skb = netdev_alloc_skb_ip_align(priv->dev,frame_len);
if (unlikely(!skb)) {
    if (net_ratelimit())
        dev_warn(priv->device,"packet dropped\n");
    priv->dev->stats.rx_dropped++;
    continue;
}

dma_sync_single_for_cpu(priv->device,rx_q->rx_skbuff_dma
            [entry],frame_len,DMA_FROM_DEVICE);

// Here I check if data has been corrupted (the answer is ALWAYS NO).
debug_check_data_corruption();

skb_copy_to_linear_data(skb,rx_q->
            rx_skbuff[entry]->data,frame_len);

// Here I check again if data has been corrupted (the answer is SOMETIMES YES).
debug_check_data_corruption();

skb_put(skb,frame_len);
dma_sync_single_for_device(priv->device,rx_q->rx_skbuff_dma
               [entry],DMA_FROM_DEVICE);

最后一些注意事项：

我尝试在启用CONFIG_DMA_API_DEBUG的情况下运行内核。它并非总是触发的，但是当我自己（通过调试功能）发现损坏时，有时我看到/sys/kernel/debug/dma-api/num_errors已经增加，有时我还会看到以下日志：DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x000000006879f902] [size=61 bytes]
我还启用了CONFIG_DEBUG_KMEMLEAK，并在捕获数据损坏事件后立即收到以下日志：kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak)，但我仍然不明白它抛出了什么线索，尽管看上去取自我在此处粘贴的同一部分代码（__netdev_alloc_skb被称为__netdev_alloc_skb_ip_align）。 /sys/kernel/debug/kmemleak显示的内容：

unreferenced object 0xe9ea52c0 (size 192):     
  comm "softirq",pid 0,jiffies 6171209 (age 32709.360s)     
  hex dump (first 32 bytes):  
        00 00 00 00 00 00 00 00 00 00 00 00 40 4d 2d ea  ............@M-.  
        00 00 00 00 00 00 00 00 d4 83 7c b3 7a 87 7c b3  ..........|.z.|.     
  backtrace:  
        [<045ac811>] __netdev_alloc_skb+0x9f/0xdc  
        [<4f2b009a>] stmmac_napi_poll+0x89b/0xfc4  
        [<1dd85c70>] net_rx_action+0xd3/0x28c  
        [<1c60fabb>] __do_softirq+0xd5/0x27c  
        [<9e007b1d>] irq_exit+0x8f/0xc0  
        [<beb36a07>] __handle_domain_irq+0x49/0x84  
        [<67c17c88>] gic_handle_irq+0x39/0x68  
        [<e8f5dc30>] __irq_svc+0x65/0x94  
        [<075bc7c7>] down_read+0x8/0x3c  
        [<075bc7c7>] down_read+0x8/0x3c  
        [<790c6556>] get_user_pages_unlocked+0x49/0x13c  
        [<544d56e3>] get_futex_key+0x77/0x2e0  
        [<1fd5d0e9>] futex_wait_setup+0x3f/0x144  
        [<8bc86dff>] futex_wait+0xa1/0x198  
        [<b362fbc0>] do_futex+0xd3/0x9a8  
        [<46f336be>] sys_futex+0xcd/0x138

来自DMA的memcpy数据损坏

如何解决来自DMA的memcpy数据损坏

相关推荐