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

e1000: add dummy allocator to fix race condition between mtu change and netpoll

2015-09-18T01:20:23+00:00

commit 08e8331654d1d7b2c58045e549005bc356aa7810 upstream.

There is a race condition between e1000_change_mtu's cleanups and
netpoll, when we change the MTU across jumbo size:

Changing MTU frees all the rx buffers:
    e1000_change_mtu -> e1000_down -> e1000_clean_all_rx_rings ->
        e1000_clean_rx_ring

Then, close to the end of e1000_change_mtu:
    pr_info -> ... -> netpoll_poll_dev -> e1000_clean ->
        e1000_clean_rx_irq -> e1000_alloc_rx_buffers -> e1000_alloc_frag

And when we come back to do the rest of the MTU change:
    e1000_up -> e1000_configure -> e1000_configure_rx ->
        e1000_alloc_jumbo_rx_buffers

alloc_jumbo finds the buffers already != NULL, since data (shared with
page in e1000_rx_buffer->rxbuf) has been re-alloc'd, but it's garbage,
or at least not what is expected when in jumbo state.

This results in an unusable adapter (packets don't get through), and a
NULL pointer dereference on the next call to e1000_clean_rx_ring
(other mtu change, link down, shutdown):

BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [] put_compound_page+0x7e/0x330

    [...]

Call Trace:
 [] put_page+0x55/0x60
 [] e1000_clean_rx_ring+0x134/0x200
 [] e1000_clean_all_rx_rings+0x45/0x60
 [] e1000_down+0x1c0/0x1d0
 [] ? deactivate_slab+0x7f0/0x840
 [] e1000_change_mtu+0xdc/0x170
 [] dev_set_mtu+0xa0/0x140
 [] do_setlink+0x218/0xac0
 [] ? nla_parse+0xb9/0x120
 [] rtnl_newlink+0x6d0/0x890
 [] ? kvm_clock_read+0x20/0x40
 [] ? sched_clock_cpu+0xa8/0x100
 [] rtnetlink_rcv_msg+0x92/0x260

By setting the allocator to a dummy version, netpoll can't mess up our
rx buffers.  The allocator is set back to a sane value in
e1000_configure_rx.

Fixes: edbbb3ca1077 ("e1000: implement jumbo receive with partial descriptors")
Signed-off-by: Sabrina Dubroca 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Zefan Li

ixgbevf: Prevent RX/TX statistics getting reset to zero

2014-12-01T10:02:45+00:00

commit 936597631dd310e220544dc5c6075d924efd39b2 upstream.

The commit 4197aa7bb81877ebb06e4f2cc1b5fea2da23a7bd implements 64 bit
per ring statistics. But the driver resets the 'total_bytes' and
'total_packets' from RX and TX rings in the RX and TX interrupt
handlers to zero. This results in statistics being lost and user space
reporting RX and TX statistics as zero. This patch addresses the
issue by preventing the resetting of RX and TX ring statistics to
zero.

Signed-off-by: Narendra K 
Tested-by: Sibai Li 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Cc: Weng Meiling 
Signed-off-by: Zefan Li

ixgbe: fix registration order of driver and DCA nofitication

2014-06-07T23:02:14+00:00

commit f01fc1a82c2ee68726b400fadb156bd623b5f2f1 upstream.

ixgbe_notify_dca cannot be called before driver registration
because it expects driver's klist_devices to be allocated and
initialized. While on it make sure debugfs files are removed
when registration fails.

Signed-off-by: Jakub Kicinski 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
[bwh: Backported to 3.2: no debugfs support]
Signed-off-by: Ben Hutchings 
Cc: Qiang Huang 
Signed-off-by: Greg Kroah-Hartman

e1000e: DoS while TSO enabled caused by link partner with small MSS

2014-06-07T23:02:07+00:00

commit d821a4c4d11ad160925dab2bb009b8444beff484 upstream.

With a low enough MSS on the link partner and TSO enabled locally, the
networking stack can periodically send a very large (e.g.  64KB) TCP
message for which the driver will attempt to use more Tx descriptors than
are available by default in the Tx ring.  This is due to a workaround in
the code that imposes a limit of only 4 MSS-sized segments per descriptor
which appears to be a carry-over from the older e1000 driver and may be
applicable only to some older PCI or PCIx parts which are not supported in
e1000e.  When the driver gets a message that is too large to fit across the
configured number of Tx descriptors, it stops the upper stack from queueing
any more and gets stuck in this state.  After a timeout, the upper stack
assumes the adapter is hung and calls the driver to reset it.

Remove the unnecessary limitation of using up to only 4 MSS-sized segments
per Tx descriptor, and put in a hard failure test to catch when attempting
to check for message sizes larger than would fit in the whole Tx ring.
Refactor the remaining logic that limits the size of data per Tx descriptor
from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
Tx packet buffer as described in the hardware specification.

Also, fix the logic in the check for space in the Tx ring for the next
largest possible packet after the current one has been successfully queued
for transmit, and use the appropriate defines for default ring sizes in
e1000_probe instead of magic values.

This issue goes back to the introduction of e1000e in 2.6.24 when it was
split off from e1000.

Reported-by: Ben Hutchings 
Signed-off-by: Bruce Allan 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Cc: Qiang Huang 
Signed-off-by: Greg Kroah-Hartman

ixgbe: Fix Tx Hang issue with lldpad on 82598EB

2013-08-11T22:38:42+00:00

commit 1eb9ac14c34a948bf1538bfb9034e8ab29099a64 upstream.

This patch fixes an issue with the 82598EB device, where lldpad is causing Tx
Hangs on the card as soon as it attempts to configure DCB for the device. The
adapter will continually Tx hang and reset in a loop.

Signed-off-by: Jacob Keller 
Tested-by: Phil Schmitt 
Tested-by: Jack Morgan 
Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ixgbe: fix EICR write in ixgbe_msix_other

2013-05-08T02:51:56+00:00

commit d87d830720a1446403ed38bfc2da268be0d356d1 upstream.

Previously, the ixgbe_msix_other was writing the full 32bits of the set
interrupts, instead of only the ones which the ixgbe_msix_other is
handling. This resulted in a loss of performance when the X540's PPS feature is
enabled due to sometimes clearing queue interrupts which resulted in the driver
not getting the interrupt for cleaning the q_vector rings often enough. The fix
is to simply mask the lower 16bits off so that this handler does not write them
in the EICR, which causes them to remain high and be properly handled by the
clean_rings interrupt routine as normal.

Signed-off-by: Jacob Keller 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

e1000e: fix pci-device enable-counter balance

2013-03-14T18:29:50+00:00

commit 4e0855dff094b0d56d6b5b271e0ce7851cc1e063 upstream.

This patch removes redundant and unbalanced pci_disable_device() from
__e1000_shutdown(). pci_clear_master() is enough, device can go into
suspended state with elevated enable_cnt.

Bug was introduced in commit 23606cf5d1192c2b17912cb2ef6e62f9b11de133
("e1000e / PCI / PM: Add basic runtime PM support (rev. 4)") in v2.6.35

Signed-off-by: Konstantin Khlebnikov 
Cc: Bruce Allan 
Acked-by: Rafael J. Wysocki 
Tested-by: Borislav Petkov 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

igb: Remove artificial restriction on RQDPC stat reading

2013-02-17T18:49:26+00:00

commit ae1c07a6b7ced6c0c94c99e3b53f4e7856fa8bff upstream.

For some reason the reading of the RQDPC register was being artificially
limited to 4K.  Instead of limiting the value we should read the value and
add the full amount.  Otherwise this can lead to a misleading number of
dropped packets when the actual value is in fact much higher.

Signed-off-by: Alexander Duyck 
Tested-by: Jeff Pieper   
Signed-off-by: Jeff Kirsher 
Cc: Vinson Lee 
Signed-off-by: Greg Kroah-Hartman

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

2013-01-21T19:45:25+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

ixgbe: add support for X540-AT1

2012-12-03T19:47:11+00:00

commit df376f0de167754da9b3ece4afdb5bb8bf3fbf3e upstream.

This patch adds device support for Ethernet Controller X540-AT1.

Signed-off-by: Josh Hay 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Abdallah Chatila 
Signed-off-by: Greg Kroah-Hartman