search for: check_for_stack

...WARNING: at lib/dma-debug.c:1169 [ 33.534706] Modules linked in: dm_multipath [ 33.534709] CPU: 1 PID: 1087 Comm: ethtool Not tainted 4.3.0-rc3+ #269 [ 33.534710] task: 00000000616f9978 ti: 00000000629e4000 task.ti: 00000000629e4000 [ 33.534712] Krnl PSW : 0704d00180000000 00000000005869d2 (check_for_stack+0xb2/0x118) [ 33.534716] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3 Krnl GPRS: 000000000000006a 0000000000d60f44 000000000000005a 0000000064ee0870 [ 33.534718] 00000000005869ce 0000000000000000 0000000000000001 00000000629e7c06 [ 33.534719] 000000...

...ommit 699b045a8e43 ("net: virtio_net: notifications coalescing > support") added coalescing command support for virtio_net. However, > the coalesce commands are using buffers on the stack, which is causing > the device to see DMA errors. There should also be a complaint from > check_for_stack() in debug_dma_map_xyz(). Fix this by adding and using > coalesce params from the control_buf struct, which aligns with other > commands. > > Fixes: 699b045a8e43 ("net: virtio_net: notifications coalescing support") > Reviewed-by: Shannon Nelson <shannon.nelson at amd.c...

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. This appears to work on native and Xen x86_64 using both modern and legacy virtio-pci. It also appears to work on arm and arm64. It definitely won't work as-is on s390x, and

This switches virtio to use the DMA API unconditionally. I'm sure it breaks things, but it seems to work on x86 using virtio-pci, with and without Xen, and using both the modern 1.0 variant and the legacy variant. This appears to work on native and Xen x86_64 using both modern and legacy virtio-pci. It also appears to work on arm and arm64. It definitely won't work as-is on s390x, and