kernel/linux.git/drivers/net/ethernet/intel, branch v5.4.50

e1000e: Do not wake up the system via WOL if device wakeup is disabled

2020-06-24T15:50:52+00:00

commit 6bf6be1127f7e6d4bf39f84d56854e944d045d74 upstream. Currently the system will be woken up via WOL(Wake On LAN) even if the device wakeup ability has been disabled via sysfs: cat /sys/devices/pci0000:00/0000:00:1f.6/power/wakeup disabled The system should not be woken up if the user has explicitly disabled the wake up ability for this device. This patch clears the WOL ability of this network device if the user has disabled the wake up ability in sysfs. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver") Reported-by: "Rafael J. Wysocki" Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Chen Yu Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman

iavf: fix speed reporting over virtchnl

2020-06-24T15:50:44+00:00

[ Upstream commit e0ef26fbe2b0c62f42ba7667076dc38b693b6fb8 ] Link speeds are communicated over virtchnl using an enum virtchnl_link_speed. Currently, the highest link speed is 40Gbps which leaves us unable to reflect some speeds that an ice VF is capable of. This causes link speed to be misreported on the iavf driver. Allow for communicating link speeds using Mbps so that the proper speed can be reported for an ice VF. Moving away from the enum allows us to communicate future speed changes without requiring a new enum to be added. In order to support communicating link speeds over virtchnl in Mbps the following functionality was added: - Added u32 link_speed_mbps in the iavf_adapter structure. - Added the macro ADV_LINK_SUPPORT(_a) to determine if the VF driver supports communicating link speeds in Mbps. - Added the function iavf_get_vpe_link_status() to fill the correct link_status in the event_data union based on the ADV_LINK_SUPPORT(_a) macro. - Added the function iavf_set_adapter_link_speed_from_vpe() to determine whether or not to fill the u32 link_speed_mbps or enum virtchnl_link_speed link_speed field in the iavf_adapter structure based on the ADV_LINK_SUPPORT(_a) macro. - Do not free vf_res in iavf_init_get_resources() as vf_res will be accessed in iavf_get_link_ksettings(); memset to 0 instead. This memory is subsequently freed in iavf_remove(). Fixes: 7c710869d64e ("ice: Add handlers for VF netdevice operations") Signed-off-by: Brett Creeley Signed-off-by: Sergey Nemov Signed-off-by: Paul Greenwalt Signed-off-by: Tony Nguyen Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

igb: Report speed and duplex as unknown when device is runtime suspended

2020-06-22T07:31:19+00:00

commit 165ae7a8feb53dc47fb041357e4b253bfc927cf9 upstream. igb device gets runtime suspended when there's no link partner. We can't get correct speed under that state: $ cat /sys/class/net/enp3s0/speed 1000 In addition to that, an error can also be spotted in dmesg: [ 385.991957] igb 0000:03:00.0 enp3s0: PCIe link lost Since device can only be runtime suspended when there's no link partner, we can skip reading register and let the following logic set speed and duplex with correct status. The more generic approach will be wrap get_link_ksettings() with begin() and complete() callbacks. However, for this particular issue, begin() calls igb_runtime_resume() , which tries to rtnl_lock() while the lock is already hold by upper ethtool layer. So let's take this approach until the igb_runtime_resume() no longer needs to hold rtnl_lock. CC: stable Suggested-by: Alexander Duyck Signed-off-by: Kai-Heng Feng Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman

e1000e: Relax condition to trigger reset for ME workaround

2020-06-22T07:31:18+00:00

commit d601afcae2febc49665008e9a79e701248d56c50 upstream. It's an error if the value of the RX/TX tail descriptor does not match what was written. The error condition is true regardless the duration of the interference from ME. But the driver only performs the reset if E1000_ICH_FWSM_PCIM2PCI_COUNT (2000) iterations of 50us delay have transpired. The extra condition can lead to inconsistency between the state of hardware as expected by the driver. Fix this by dropping the check for number of delay iterations. While at it, also make __ew32_prepare() static as it's not used anywhere else. CC: stable Signed-off-by: Punit Agrawal Reviewed-by: Alexander Duyck Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman

e1000e: Disable TSO for buffer overrun workaround

2020-06-22T07:31:17+00:00

commit f29801030ac67bf98b7a65d3aea67b30769d4f7c upstream. Commit b10effb92e27 ("e1000e: fix buffer overrun while the I219 is processing DMA transactions") imposes roughly 30% performance penalty. The commit log states that "Disabling TSO eliminates performance loss for TCP traffic without a noticeable impact on CPU performance", so let's disable TSO by default to regain the loss. CC: stable Fixes: b10effb92e27 ("e1000e: fix buffer overrun while the I219 is processing DMA transactions") BugLink: https://bugs.launchpad.net/bugs/1802691 Signed-off-by: Kai-Heng Feng Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman

ixgbe: fix signed-integer-overflow warning

2020-06-22T07:31:10+00:00

[ Upstream commit 3b70683fc4d68f5d915d9dc7e5ba72c732c7315c ] ubsan report this warning, fix it by adding a unsigned suffix. UBSAN: signed-integer-overflow in drivers/net/ethernet/intel/ixgbe/ixgbe_common.c:2246:26 65535 * 65537 cannot be represented in type 'int' CPU: 21 PID: 7 Comm: kworker/u256:0 Not tainted 5.7.0-rc3-debug+ #39 Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 03/27/2020 Workqueue: ixgbe ixgbe_service_task [ixgbe] Call trace: dump_backtrace+0x0/0x3f0 show_stack+0x28/0x38 dump_stack+0x154/0x1e4 ubsan_epilogue+0x18/0x60 handle_overflow+0xf8/0x148 __ubsan_handle_mul_overflow+0x34/0x48 ixgbe_fc_enable_generic+0x4d0/0x590 [ixgbe] ixgbe_service_task+0xc20/0x1f78 [ixgbe] process_one_work+0x8f0/0xf18 worker_thread+0x430/0x6d0 kthread+0x218/0x238 ret_from_fork+0x10/0x18 Reported-by: Hulk Robot Signed-off-by: Xie XiuQi Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

ice: fix potential double free in probe unrolling

2020-06-22T07:31:10+00:00

[ Upstream commit bc3a024101ca497bea4c69be4054c32a5c349f1d ] If ice_init_interrupt_scheme fails, ice_probe will jump to clearing up the interrupts. This can lead to some static analysis tools such as the compiler sanitizers complaining about double free problems. Since ice_init_interrupt_scheme already unrolls internally on failure, there is no need to call ice_clear_interrupt_scheme when it fails. Add a new unroll label and use that instead. Signed-off-by: Jacob Keller Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

e1000: Distribute switch variables for initialization

2020-06-22T07:30:58+00:00

[ Upstream commit a34c7f5156654ebaf7eaace102938be7ff7036cb ] Variables declared in a switch statement before any case statements cannot be automatically initialized with compiler instrumentation (as they are not part of any execution flow). With GCC's proposed automatic stack variable initialization feature, this triggers a warning (and they don't get initialized). Clang's automatic stack variable initialization (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also doesn't initialize such variables[1]. Note that these warnings (or silent skipping) happen before the dead-store elimination optimization phase, so even when the automatic initializations are later elided in favor of direct initializations, the warnings remain. To avoid these problems, move such variables into the "case" where they're used or lift them up into the main function body. drivers/net/ethernet/intel/e1000/e1000_main.c: In function ‘e1000_xmit_frame’: drivers/net/ethernet/intel/e1000/e1000_main.c:3143:18: warning: statement will never be executed [-Wswitch-unreachable] 3143 | unsigned int pull_size; | ^~~~~~~~~ [1] https://bugs.llvm.org/show_bug.cgi?id=44916 Signed-off-by: Kees Cook Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

ice: Fix for memory leaks and modify ICE_FREE_CQ_BUFS

2020-06-22T07:30:56+00:00

[ Upstream commit 68d270783742783f96e89ef92ac24ab3c7fb1d31 ] Handle memory leaks during control queue initialization and buffer allocation failures. The macro ICE_FREE_CQ_BUFS is modified to re-use for this fix. Signed-off-by: Surabhi Boob Signed-off-by: Tony Nguyen Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin

ice: Fix memory leak

2020-06-22T07:30:56+00:00

[ Upstream commit 1aaef2bc4e0a5ce9e4dd86359e6a0bf52c6aa64f ] Handle memory leak on filter management initialization failure. Signed-off-by: Surabhi Boob Signed-off-by: Tony Nguyen Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin