kernel/drivers/net/ethernet/realtek, branch linux-4.3.y

r8169: fix kasan reported skb use-after-free.

2015-12-15T05:40:55Z

[ Upstream commit 39174291d8e8acfd1113214a943263aaa03c57c8 ] Signed-off-by: Francois Romieu Reported-by: Dave Jones Fixes: d7d2d89d4b0af ("r8169: Add software counter for multicast packages") Acked-by: Eric Dumazet Acked-by: Corinna Vinschen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

r8169: fix handling rtl_readphy result

2015-09-27T05:48:32Z

The function can return negative value. The problem has been detected using proposed semantic patch scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107 Signed-off-by: Andrzej Hajda Signed-off-by: David S. Miller

8139cp: Dump contents of descriptor ring on TX timeout

2015-09-23T21:47:13Z

We are seeing unexplained TX timeouts under heavy load. Let's try to get a better idea of what's going on. Signed-off-by: David Woodhouse Signed-off-by: David S. Miller

8139cp: Fix DMA unmapping of transmitted buffers

2015-09-23T21:47:13Z

The low 16 bits of the 'opts1' field in the TX descriptor are supposed to still contain the buffer length when the descriptor is handed back to us. In practice, at least on my hardware, they don't. So stash the original value of the opts1 field and get the length to unmap from there. There are other ways we could have worked out the length, but I actually want a stash of the opts1 field anyway so that I can dump it alongside the contents of the descriptor ring when we suffer a TX timeout. Signed-off-by: David Woodhouse Signed-off-by: David S. Miller

8139cp: Reduce duplicate csum/tso code in cp_start_xmit()

2015-09-23T21:47:12Z

We calculate the value of the opts1 descriptor field in three different places. With two different behaviours when given an invalid packet to be checksummed — none of them correct. Sort that out. Signed-off-by: David Woodhouse Signed-off-by: David S. Miller

8139cp: Fix TSO/scatter-gather descriptor setup

2015-09-23T21:47:12Z

When sending a TSO frame in multiple buffers, we were neglecting to set the first descriptor up in TSO mode. Signed-off-by: David Woodhouse Signed-off-by: David S. Miller

8139cp: Fix tx_queued debug message to print correct slot numbers

2015-09-23T21:47:12Z

After a certain amount of staring at the debug output of this driver, I realised it was lying to me. Signed-off-by: David Woodhouse Signed-off-by: David S. Miller

8139cp: Do not re-enable RX interrupts in cp_tx_timeout()

2015-09-23T21:47:12Z

If an RX interrupt was already received but NAPI has not yet run when the RX timeout happens, we end up in cp_tx_timeout() with RX interrupts already disabled. Blindly re-enabling them will cause an IRQ storm. (This is made particularly horrid by the fact that cp_interrupt() always returns that it's handled the interrupt, even when it hasn't actually done anything. If it didn't do that, the core IRQ code would have detected the storm and handled it, I'd have had a clear smoking gun backtrace instead of just a spontaneously resetting router, and I'd have at *least* two days of my life back. Changing the return value of cp_interrupt() will be argued about under separate cover.) Unconditionally leave RX interrupts disabled after the reset, and schedule NAPI to check the receive ring and re-enable them. Signed-off-by: David Woodhouse Signed-off-by: David S. Miller

8139cp: Call __cp_set_rx_mode() from cp_tx_timeout()

2015-09-21T05:23:40Z

Unless we reset the RX config, on real hardware I don't seem to receive any packets after a TX timeout. Signed-off-by: David Woodhouse Signed-off-by: David S. Miller

8139cp: Use dev_kfree_skb_any() instead of dev_kfree_skb() in cp_clean_rings()

2015-09-21T05:23:40Z

This can be called from cp_tx_timeout() with interrupts disabled. Spotted by Francois Romieu Signed-off-by: David Woodhouse Signed-off-by: David S. Miller