linux-stable.git/drivers/net/ethernet, branch linux-3.7.y

via-rhine: Fix bugs in NAPI support.

2013-02-14T18:48:18+00:00

[ Upstream commit 559bcac35facfed49ab4f408e162971612dcfdf3 ]

1) rhine_tx() should use dev_kfree_skb() not dev_kfree_skb_irq()

2) rhine_slow_event_task's NAPI triggering logic is racey, it
   should just hit the interrupt mask register.  This is the
   same as commit 7dbb491878a2c51d372a8890fa45a8ff80358af1
   ("r8169: avoid NAPI scheduling delay.") made to fix the same
   problem in the r8169 driver.  From Francois Romieu.

Reported-by: Jamie Gloudon 
Tested-by: Jamie Gloudon 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

r8169: remove the obsolete and incorrect AMD workaround

2013-02-14T18:48:15+00:00

[ Upstream commit 5d0feaff230c0abfe4a112e6f09f096ed99e0b2d ]

This was introduced in commit 6dccd16 "r8169: merge with version
6.001.00 of Realtek's r8169 driver". I did not find the version
6.001.00 online, but in 6.002.00 or any later r8169 from Realtek
this hunk is no longer present.

Also commit 05af214 "r8169: fix Ethernet Hangup for RTL8110SC
rev d" claims to have fixed this issue otherwise.

The magic compare mask of 0xfffe000 is dubious as it masks
parts of the Reserved part, and parts of the VLAN tag. But this
does not make much sense as the VLAN tag parts are perfectly
valid there. In matter of fact this seems to be triggered with
any VLAN tagged packet as RxVlanTag bit is matched. I would
suspect 0xfffe0000 was intended to test reserved part only.

Finally, this hunk is evil as it can cause more packets to be
handled than what was NAPI quota causing net/core/dev.c:
net_rx_action(): WARN_ON_ONCE(work > weight) to trigger, and
mess up the NAPI state causing device to hang.

As result, any system using VLANs and having high receive
traffic (so that NAPI poll budget limits rtl_rx) would result
in device hang.

Signed-off-by: Timo Teräs 
Acked-by: Francois Romieu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netxen: fix off by one bug in netxen_release_tx_buffer()

2013-02-14T18:48:14+00:00

[ Upstream commit a05948f296ce103989b28a2606e47d2e287c3c89 ]

Christoph Paasch found netxen could trigger a BUG in its dismantle
phase, in netxen_release_tx_buffer(), using full size TSO packets.

cmd_buf->frag_count includes the skb->data part, so the loop must
start at index 1 instead of 0, or else we can make an out
of bound access to cmd_buff->frag_array[MAX_SKB_FRAGS + 2]

Christoph provided the fixes in netxen_map_tx_skb() function.
In case of a dma mapping error, its better to clear the dma fields
so that we don't try to unmap them again in netxen_release_tx_buffer()

Reported-by: Christoph Paasch 
Signed-off-by: Eric Dumazet 
Tested-by: Christoph Paasch 
Cc: Sony Chacko 
Cc: Rajesh Borundia 
Signed-off-by: Christoph Paasch 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/mlx4_core: Set number of msix vectors under SRIOV mode to firmware defaults

2013-02-14T18:48:11+00:00

[ Upstream commit ca4c7b35f75492de7fbf5ee95be07481c348caee ]

The lines

	if (mlx4_is_mfunc(dev)) {
		nreq = 2;
	} else {

which hard code the number of requested msi-x vectors under multi-function
mode to two can be removed completely, since the firmware sets num_eqs and
reserved_eqs appropriately Thus, the code line:

	nreq = min_t(int, dev->caps.num_eqs - dev->caps.reserved_eqs, nreq);

is by itself sufficient and correct for all cases. Currently, for mfunc
mode num_eqs = 32 and reserved_eqs = 28, hence four vectors will be enabled.

This triples (one vector is used for the async events and commands EQ) the
horse power provided for processing of incoming packets on netdev RSS scheme,
IO initiators/targets commands processing flows, etc.

Reviewed-by: Jack Morgenstein 
Signed-off-by: Amir Vadai 
Signed-off-by: Or Gerlitz 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/mlx4_en: Fix bridged vSwitch configuration for non SRIOV mode

2013-02-14T18:48:10+00:00

[ Upstream commit 213815a1e6ae70b9648483b110bc5081795f99e8 ]

Commit 5b4c4d36860e "mlx4_en: Allow communication between functions on
same host" introduced a regression under which a bridge acting as vSwitch
whose uplink is an mlx4 Ethernet device become non-operative in native
(non sriov) mode. This happens since broadcast ARP requests sent by VMs
were loopback-ed by the HW and hence the bridge learned VM source MACs
on both the VM and the uplink ports.

The fix is to place the DMAC in the send WQE only under SRIOV/eSwitch
configuration or when the device is in selftest.

Reviewed-by: Or Gerlitz 
Signed-off-by: Yan Burman 
Signed-off-by: Amir Vadai 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: calxedaxgmac: throw away overrun frames

2013-02-14T18:48:09+00:00

[ Upstream commit d6fb3be544b46a7611a3373fcaa62b5b0be01888 ]

The xgmac driver assumes 1 frame per descriptor. If a frame larger than
the descriptor's buffer size is received, the frame will spill over into
the next descriptor. So check for received frames that span more than one
descriptor and discard them. This prevents a crash if we receive erroneous
large packets.

Signed-off-by: Rob Herring 
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

e1000e: enable ECC on I217/I218 to catch packet buffer memory errors

2013-02-14T18:48:00+00:00

commit 286003048aaef49b26bb9d93611dc69085e8982e upstream.

In rare instances, memory errors have been detected in the internal packet
buffer memory on I217/I218 when stressed under certain environmental
conditions.  Enable Error Correcting Code (ECC) in hardware to catch both
correctable and uncorrectable errors.  Correctable errors will be handled
by the hardware.  Uncorrectable errors in the packet buffer will cause the
packet to be received with an error indication in the buffer descriptor
causing the packet to be discarded.  If the uncorrectable error is in the
descriptor itself, the hardware will stop and interrupt the driver
indicating the error.  The driver will then reset the hardware in order to
clear the error and restart.

Both types of errors will be accounted for in statistics counters.

Signed-off-by: Bruce Allan 
Tested-by: Jeff Pieper 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

igb: release already assigned MSI-X interrupts if setup fails

2013-01-21T19:44:44+00:00

commit 52285b762b3681669215bf1d17ca6143448ab7d3 upstream.

During MSI-X setup the system might run out of vectors. If this happens the
already assigned vectors for this NIC should be freed before trying the
disable MSI-X. Failing to do so results in the following oops.

kernel BUG at drivers/pci/msi.c:341!
[...]
Call Trace:
 [] pci_disable_msix+0x3d/0x60
 [] igb_reset_interrupt_capability+0x27/0x5c [igb]
 [] igb_clear_interrupt_scheme+0x26/0x2d [igb]
 [] igb_request_irq+0x73/0x297 [igb]
 [] __igb_open+0xc8/0x223 [igb]
 [] igb_open+0x13/0x15 [igb]
 [] __dev_open+0xbf/0x120
 [] __dev_change_flags+0xa1/0x180
 [] dev_change_flags+0x28/0x70
 [] devinet_ioctl+0x5b7/0x620
 [] inet_ioctl+0x88/0xa0
 [] sock_do_ioctl+0x30/0x70
 [] sock_ioctl+0x72/0x270
 [] do_vfs_ioctl+0x8c/0x340
 [] sys_ioctl+0xa1/0xb0
 [] system_call_fastpath+0x16/0x1b
Code: 48 89 df e8 1f 40 ed ff 4d 39 e6 49 8b 45 10 75 b6 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 8b 7b 20 e8 3e 91 db ff eb ae <0f> 0b eb fe 0f 1f 84 00 00 00 00 00 55 48 89 e5 0f 1f 44 00 00
RIP  [] free_msi_irqs+0x124/0x130
 RSP 

Signed-off-by: Stefan Assmann 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Abdallah Chatila

mlx4_core: Fix potential deadlock in mlx4_eq_int()

2013-01-17T16:45:58+00:00

commit 311f813a2daefcba03f706a692fe0c67888d7622 upstream.

The slave_state_lock spinlock is used in both interrupt context and
process context, hence irq locking must be used.  Found by lockdep.

Signed-off-by: Jack Morgenstein 
Signed-off-by: Or Gerlitz 
Signed-off-by: Roland Dreier 
Signed-off-by: Greg Kroah-Hartman

8139cp: fix coherent mapping leak in error path.

2012-12-02T01:39:17+00:00

cp_open
[...]
        rc = cp_alloc_rings(cp);
        if (rc)
                return rc;

cp_alloc_rings
[...]
        mem = dma_alloc_coherent(&cp->pdev->dev, CP_RING_BYTES,
                                 &cp->ring_dma, GFP_KERNEL);

- cp_alloc_rings never frees the coherent mapping it allocates
- neither do cp_open when cp_alloc_rings fails

Signed-off-by: Francois Romieu 
Signed-off-by: David S. Miller