kernel.git/drivers/net/ethernet, branch linux-4.7.y

i40e: avoid NULL pointer dereference and recursive errors on early PCI error

2016-10-22T10:06:47Z

commit edfc23ee3e0ebbb6713d7574ab1b00abff178f6c upstream. Although rare, it's possible to hit PCI error early on device probe, meaning possibly some structs are not entirely initialized, and some might even be completely uninitialized, leading to NULL pointer dereference. The i40e driver currently presents a "bad" behavior if device hits such early PCI error: firstly, the struct i40e_pf might not be attached to pci_dev yet, leading to a NULL pointer dereference on access to pf->state. Even checking if the struct is NULL and avoiding the access in that case isn't enough, since the driver cannot recover from PCI error that early; in our experiments we saw multiple failures on kernel log, like: [549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15 [549.664] i40e: probe of 0007:01:00.1 failed with error -15 [...] [871.644] i40e 0007:01:00.1: The driver for the device stopped because the device firmware failed to init. Try updating your NVM image. [871.644] i40e: probe of 0007:01:00.1 failed with error -32 [...] [872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored Between the first probe failure (error -15) and the second (error -32) another PCI error happened due to the first bad probe. Also, driver started to flood console with those ARQ event messages. This patch will prevent these issues by allowing error recovery mechanism to remove the failed device from the system instead of trying to recover from early PCI errors during device probe. Signed-off-by: Guilherme G Piccoli Acked-by: Jacob Keller Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

fm10k: fix incorrect index calculation in fm10k_write_reta

2016-10-07T13:21:23Z

commit 34875887f360d7bd0b7f0a89f7c6d65eca616ee3 upstream. The index calculated when looping through the indir array passed to fm10k_write_reta was incorrectly calculated as the first part i needs to be multiplied by 4. Fixes: 0cfea7a65738 ("fm10k: fix possible null pointer deref after kcalloc", 2016-04-13) Signed-off-by: Jacob Keller Tested-by: Krishneil Singh Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman

i40e: avoid null pointer dereference

2016-10-07T13:21:17Z

commit cd956722167ba4fdba9c1ce3eed251b04ea2e10f upstream. In function i40e_debug_aq parameter desc is assumed to be possibly NULL. Do not dereference it before checking the value. Fixes: f905dd62be88 ("i40e/i40evf: add max buf len to aq debug print helper") Signed-off-by: Heinrich Schuchardt Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman

igb: fix adjusting PTP timestamps for Tx/Rx latency

2016-09-30T08:12:48Z

commit 0066c8b6f4050d7c57f6379d6fd4535e2f267f17 upstream. Fix PHY delay compensation math in igb_ptp_tx_hwtstamp() and igb_ptp_rx_rgtstamp. Add PHY delay compensation in igb_ptp_rx_pktstamp(). In the IGB driver, there are two functions that retrieve timestamps received by the PHY - igb_ptp_rx_rgtstamp() and igb_ptp_rx_pktstamp(). The previous commit only changed igb_ptp_rx_rgtstamp(), and the change was incorrect. There are two instances in which PHY delay compensations should be made: - Before the packet transmission over the PHY, the latency between when the packet is timestamped and transmission of the packets, should be an add operation, but it is currently a subtract. - After the packets are received from the PHY, the latency between the receiving and timestamping of the packets should be a subtract operation, but it is currently an add. Signed-off-by: Kshitiz Gupta Fixes: 3f544d2 (igb: adjust ptp timestamps for tx/rx latency) Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman

ixgbe: Re-enable ability to toggle VLAN filtering

2016-09-30T08:12:48Z

commit 3d951822be216d8c6fcfc8abf75e5ed307eeb646 upstream. Back when I submitted the GSO code I messed up and dropped the support for disabling the VLAN tag filtering via the feature bit. This patch re-enables the use of the NETIF_F_HW_VLAN_CTAG_FILTER to enable/disable the VLAN filtering independent of toggling promiscuous mode. Fixes: b83e30104b ("ixgbe/ixgbevf: Add support for GSO partial") Signed-off-by: Alexander Duyck Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman

ixgbe: Force VLNCTRL.VFE to be set in all VMDq paths

2016-09-30T08:12:48Z

commit f60439bc21e3337429838e477903214f5bd8277f upstream. When I was adding the code for enabling VLAN promiscuous mode with SR-IOV enabled I had inadvertently left the VLNCTRL.VFE bit unchanged as I has assumed there was code in another path that was setting it when we enabled SR-IOV. This wasn't the case and as a result we were just disabling VLAN filtering for all the VFs apparently. Also the previous patches were always clearing CFIEN which was always set to 0 by the hardware anyway so I am dropping the redundant bit clearing. Fixes: 16369564915a ("ixgbe: Add support for VLAN promiscuous with SR-IOV") Signed-off-by: Alexander Duyck Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman

net: macb: Correct CAPS mask

2016-09-24T08:09:32Z

commit c518189567eaf42b2ec50a4d982484c8e38799f8 upstream. USRIO and JUMBO CAPS have the same mask. Fix the same. Fixes: ce721a702197 ("net: ethernet: cadence-macb: Add disabled usrio caps") Signed-off-by: Harini Katakam Acked-by: Nicolas Ferre Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: thunderx: Fix OOPs with ethtool --register-dump

2016-09-24T08:09:32Z

commit 1423661fed2c40d6d71b5e2e3aa390f85157f9d5 upstream. The ethtool_ops .get_regs function attempts to read the nonexistent register NIC_QSET_SQ_0_7_CNM_CHG, which produces a "bus error" type OOPs. Fix by not attempting to read, and removing the definition of, NIC_QSET_SQ_0_7_CNM_CHG. A zero is written into the register dump to keep the layout unchanged. Signed-off-by: David Daney Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net/mlx5e: Fix parsing of vlan packets when updating lro header

2016-09-24T08:09:26Z

[ Upstream commit cd17d230dd060a12f7451c0caeedb3fd5158eaf9 ] Currently vlan tagged packets were not parsed correctly and assumed to be regular IPv4/IPv6 packets. We should check for 802.1Q/802.1ad tags and update the lro header accordingly. This fixes the use case where LRO is on and rxvlan is off (vlan stripping is off). Fixes: e586b3b0baee ('net/mlx5: Ethernet Datapath files') Signed-off-by: Gal Pressman Signed-off-by: Saeed Mahameed Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bnxt_en: Fix TX push operation on ARM64.

2016-09-24T08:09:26Z

[ Upstream commit 9d13744bb75078175ab49408f2abb980e4dbccc9 ] There is a code path where we are calling __iowrite64_copy() on an address that is not 64-bit aligned. This causes an exception on some architectures such as arm64. Fix that code path by using __iowrite32_copy(). Reported-by: JD Zheng Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman