moxart_mac_start_xmit() doesn't care where the tail is, head can catch up and pass the tail multiple times without ever calling moxart_tx_finished() (called from IRQ handler). This is especially bad under congestion when dev_kfree_skb_irq() is not called for large numbers of skbs, see slabinfo comparison below: [root@zurkon ~]# cat /proc/slabinfo > /root/slabinfo [ 140.280000] moxart-ethernet 90900000.ethernet eth0: moxart_mac_start_xmit tx_head=63 tx_tail=47 .. (1-62 printed, moxart_tx_finished() never called) [ 140.290000] moxart-ethernet 90900000.ethernet eth0: moxart_mac_start_xmit tx_head=0 tx_tail=47 .. (1-62 printed, moxart_tx_finished() never called) [ 140.880000] moxart-ethernet 90900000.ethernet eth0: moxart_mac_start_xmit tx_head=63 tx_tail=47 [ 140.890000] moxart-ethernet 90900000.ethernet eth0: moxart_mac_start_xmit tx_head=0 tx_tail=47 .. (1-38 printed, moxart_tx_finished() never called) [ 141.260000] moxart-ethernet 90900000.ethernet eth0: moxart_mac_start_xmit tx_head=39 tx_tail=47 [ 141.270000] moxart-ethernet 90900000.ethernet eth0: moxart_tx_finished: 47 .. (48-38 moxart_tx_finished()) [ 141.270000] moxart-ethernet 90900000.ethernet eth0: moxart_tx_finished: 39 [ 141.290000] moxart-ethernet 90900000.ethernet eth0: moxart_mac_start_xmit tx_head=40 tx_tail=40 [root@zurkon ~]# cat /root/slabinfo | grep kmallo kmalloc-8192 4 4 8192 4 8 : tunables 0 0 0 : slabdata 1 1 0 kmalloc-4096 15 16 4096 8 8 : tunables 0 0 0 : slabdata 2 2 0 kmalloc-2048 50 56 2048 8 4 : tunables 0 0 0 : slabdata 7 7 0 kmalloc-1024 44 48 1024 8 2 : tunables 0 0 0 : slabdata 6 6 0 kmalloc-512 173 176 512 8 1 : tunables 0 0 0 : slabdata 22 22 0 kmalloc-256 112 112 256 16 1 : tunables 0 0 0 : slabdata 7 7 0 kmalloc-192 222 252 192 21 1 : tunables 0 0 0 : slabdata 12 12 0 kmalloc-128 138 192 128 32 1 : tunables 0 0 0 : slabdata 6 6 0 kmalloc-96 400 420 96 42 1 : tunables 0 0 0 : slabdata 10 10 0 kmalloc-64 366 384 64 64 1 : tunables 0 0 0 : slabdata 6 6 0 kmalloc-32 1985 2048 32 128 1 : tunables 0 0 0 : slabdata 16 16 0 [root@zurkon ~]# cat /proc/slabinfo | grep kmalloc kmalloc-8192 4 4 8192 4 8 : tunables 0 0 0 : slabdata 1 1 0 kmalloc-4096 15 16 4096 8 8 : tunables 0 0 0 : slabdata 2 2 0 kmalloc-2048 2259 2288 2048 8 4 : tunables 0 0 0 : slabdata 286 286 0 kmalloc-1024 55 56 1024 8 2 : tunables 0 0 0 : slabdata 7 7 0 kmalloc-512 175 176 512 8 1 : tunables 0 0 0 : slabdata 22 22 0 kmalloc-256 112 112 256 16 1 : tunables 0 0 0 : slabdata 7 7 0 kmalloc-192 4446 4494 192 21 1 : tunables 0 0 0 : slabdata 214 214 0 kmalloc-128 141 224 128 32 1 : tunables 0 0 0 : slabdata 7 7 0 kmalloc-96 400 420 96 42 1 : tunables 0 0 0 : slabdata 10 10 0 kmalloc-64 402 512 64 64 1 : tunables 0 0 0 : slabdata 8 8 0 kmalloc-32 1976 2048 32 128 1 : tunables 0 0 0 : slabdata 16 16 0 https://bitbucket.org/Kasreyn/linux-next/commits/746afa1beb9768a6f4082afcfb28ee2ea1d24864
The following patch should fix this: "net: moxa: fix TX overrun memory leak" https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=c2b341a620018d4eaeb0e85c16274ac4e5f153d4 Though the text in my previous note still applies (commit 746afa1beb9768a6f4082afcfb28ee2ea1d24864), the severity of the leak was inflated by failing to re-enable the interrupts: https://bitbucket.org/Kasreyn/linux-next/commits/2e0be24d5ea456f0a0201f6cfb4fb71447586797?at=moxart-ethernet-stop-wake-queue