RE: [Intel-wired-lan] [PATCH 4/4] ixgbe/ixgbe_ethtool.c: Remove unnecessary usages of memset.
> -Original Message- > From: Intel-wired-lan On Behalf Of > Suraj Upadhyay > Sent: Tuesday, July 14, 2020 12:42 PM > To: Kirsher, Jeffrey T ; da...@davemloft.net; > k...@kernel.org > Cc: net...@vger.kernel.org; kernel-janit...@vger.kernel.org; intel-wired- > l...@lists.osuosl.org; linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH 4/4] ixgbe/ixgbe_ethtool.c: Remove > unnecessary usages of memset. > > Replace memsets of 1 byte with simple assignment. > Issue found with checkpatch.pl > > Signed-off-by: Suraj Upadhyay > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH] ixgbe: use eth_zero_addr() to clear mac address
> -Original Message- > From: Intel-wired-lan On Behalf Of > linmiaohe > Sent: Monday, July 20, 2020 1:28 AM > To: Kirsher, Jeffrey T ; da...@davemloft.net; > k...@kernel.org > Cc: linmia...@huawei.com; net...@vger.kernel.org; intel-wired- > l...@lists.osuosl.org; linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH] ixgbe: use eth_zero_addr() to clear mac > address > > From: Miaohe Lin > > Use eth_zero_addr() to clear mac address insetad of memset(). > > Signed-off-by: Miaohe Lin > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH v1 1/5] iavf: use generic power management
> -Original Message- > From: Intel-wired-lan On Behalf Of > Vaibhav Gupta > Sent: Monday, June 29, 2020 2:30 AM > To: Bjorn Helgaas ; Bjorn Helgaas > ; bj...@helgaas.com; Vaibhav Gupta > ; David S. Miller ; > Jakub Kicinski ; Kirsher, Jeffrey T > > Cc: Vaibhav Gupta ; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; > sk...@linuxfoundation.org; linux-kernel- > ment...@lists.linuxfoundation.org > Subject: [Intel-wired-lan] [PATCH v1 1/5] iavf: use generic power > management > > With the support of generic PM callbacks, drivers no longer need to use > legacy .suspend() and .resume() in which they had to maintain PCI states > changes and device's power state themselves. The required operations are > done by PCI core. > > PCI drivers are not expected to invoke PCI helper functions like > pci_save/restore_state(), pci_enable/disable_device(), > pci_set_power_state(), etc. Their tasks are completed by PCI core itself. > > Compile-tested only. > > Signed-off-by: Vaibhav Gupta > --- > drivers/net/ethernet/intel/iavf/iavf_main.c | 45 ++--- > 1 file changed, 12 insertions(+), 33 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH v1 4/5] ixgbevf: use generic power management
> -Original Message- > From: Intel-wired-lan On Behalf Of > Vaibhav Gupta > Sent: Monday, June 29, 2020 2:30 AM > To: Bjorn Helgaas ; Bjorn Helgaas > ; bj...@helgaas.com; Vaibhav Gupta > ; David S. Miller ; > Jakub Kicinski ; Kirsher, Jeffrey T > > Cc: Vaibhav Gupta ; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; > sk...@linuxfoundation.org; linux-kernel- > ment...@lists.linuxfoundation.org > Subject: [Intel-wired-lan] [PATCH v1 4/5] ixgbevf: use generic power > management > > With legacy PM, drivers themselves were responsible for managing the > device's power states and takes care of register states. > > After upgrading to the generic structure, PCI core will take care of required > tasks and drivers should do only device-specific operations. > > The driver was invoking PCI helper functions like pci_save/restore_state(), > and pci_enable/disable_device(), which is not recommended. > > Compile-tested only. > > Signed-off-by: Vaibhav Gupta > --- > .../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 44 +-- > 1 file changed, 10 insertions(+), 34 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH v1 3/5] ixgbe: use generic power management
> -Original Message- > From: Intel-wired-lan On Behalf Of > Vaibhav Gupta > Sent: Monday, June 29, 2020 2:30 AM > To: Bjorn Helgaas ; Bjorn Helgaas > ; bj...@helgaas.com; Vaibhav Gupta > ; David S. Miller ; > Jakub Kicinski ; Kirsher, Jeffrey T > > Cc: Vaibhav Gupta ; net...@vger.kernel.org; > linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; > sk...@linuxfoundation.org; linux-kernel- > ment...@lists.linuxfoundation.org > Subject: [Intel-wired-lan] [PATCH v1 3/5] ixgbe: use generic power > management > > With legacy PM hooks, it was the responsibility of a driver to manage PCI > states and also the device's power state. The generic approach is to let PCI > core handle the work. > > ixgbe_suspend() calls __ixgbe_shutdown() to perform intermediate tasks. > __ixgbe_shutdown() modifies the value of "wake" (device should be > wakeup enabled or not), responsible for controlling the flow of legacy PM. > > Since, PCI core has no idea about the value of "wake", new code for generic > PM may produce unexpected results. Thus, use > "device_set_wakeup_enable()" > to wakeup-enable the device accordingly. > > Compile-tested only. > > Signed-off-by: Vaibhav Gupta > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 61 +-- > 1 file changed, 15 insertions(+), 46 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH] i40e: silence an UBSAN false positive
> -Original Message- > From: Intel-wired-lan On Behalf Of > Qian Cai > Sent: Saturday, June 6, 2020 1:01 PM > To: Kirsher, Jeffrey T > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; Qian Cai > ; intel-wired-...@lists.osuosl.org; da...@davemloft.net > Subject: [Intel-wired-lan] [PATCH] i40e: silence an UBSAN false positive > > virtchnl_rss_lut.lut is used for the RSS lookup table, but in > i40e_vc_config_rss_lut(), it is indexed by subscript results in a false > positive. > > UBSAN: array-index-out-of-bounds in > drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:2983:15 > index 1 is out of range for type 'u8 [1]' > CPU: 34 PID: 871 Comm: kworker/34:2 Not tainted 5.7.0-next-20200605+ #5 > Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 > 03/09/2018 > Workqueue: i40e i40e_service_task [i40e] Call Trace: > dump_stack+0xa7/0xea > ubsan_epilogue+0x9/0x45 > __ubsan_handle_out_of_bounds+0x6f/0x80 > i40e_vc_process_vf_msg+0x457c/0x4660 [i40e] > i40e_service_task+0x96c/0x1ab0 [i40e] > process_one_work+0x57d/0xbd0 > worker_thread+0x63/0x5b0 > kthread+0x20c/0x230 > ret_from_fork+0x22/0x30 > > Fixes: d510497b8397 ("i40e: add input validation for virtchnl handlers") > Signed-off-by: Qian Cai > --- > drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH net-next] i40e: Make i40e_shutdown_adminq() return void
-Original Message- From: Intel-wired-lan On Behalf Of Jason Yan Sent: Tuesday, May 5, 2020 11:19 PM To: Kirsher, Jeffrey T ; da...@davemloft.net; Azarewicz, Piotr ; intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org Cc: Jason Yan Subject: [Intel-wired-lan] [PATCH net-next] i40e: Make i40e_shutdown_adminq() return void Fix the following coccicheck warning: drivers/net/ethernet/intel/i40e/i40e_adminq.c:699:13-21: Unneeded variable: "ret_code". Return "0" on line 710 Signed-off-by: Jason Yan --- drivers/net/ethernet/intel/i40e/i40e_adminq.c| 6 +- drivers/net/ethernet/intel/i40e/i40e_prototype.h | 2 +- 2 files changed, 2 insertions(+), 6 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH net-next] ixgbe: Use true, false for bool variable in __ixgbe_enable_sriov()
-Original Message- From: Intel-wired-lan On Behalf Of Jason Yan Sent: Tuesday, May 5, 2020 12:44 AM To: Kirsher, Jeffrey T ; da...@davemloft.net; a...@kernel.org; dan...@iogearbox.net; k...@kernel.org; h...@kernel.org; john.fastab...@gmail.com; intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org; b...@vger.kernel.org Cc: Jason Yan Subject: [Intel-wired-lan] [PATCH net-next] ixgbe: Use true, false for bool variable in __ixgbe_enable_sriov() Fix the following coccicheck warning: drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c:105:2-38: WARNING: Assignment of 0/1 to bool variable Signed-off-by: Jason Yan --- drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH net-next] ixgbe: Remove conversion to bool in ixgbe_device_supports_autoneg_fc()
-Original Message- From: Intel-wired-lan On Behalf Of Jason Yan Sent: Tuesday, May 5, 2020 12:42 AM To: Kirsher, Jeffrey T ; da...@davemloft.net; intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org Cc: Jason Yan Subject: [Intel-wired-lan] [PATCH net-next] ixgbe: Remove conversion to bool in ixgbe_device_supports_autoneg_fc() No need to convert '==' expression to bool. This fixes the following coccicheck warning: drivers/net/ethernet/intel/ixgbe/ixgbe_common.c:68:11-16: WARNING: conversion to bool not needed here Signed-off-by: Jason Yan --- drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH net-next] ixgbe: Remove unused inline function ixgbe_irq_disable_queues
-Original Message- From: Intel-wired-lan On Behalf Of YueHaibing Sent: Tuesday, May 5, 2020 1:36 AM To: Kirsher, Jeffrey T ; da...@davemloft.net Cc: net...@vger.kernel.org; YueHaibing ; intel-wired-...@lists.osuosl.org; linux-kernel@vger.kernel.org Subject: [Intel-wired-lan] [PATCH net-next] ixgbe: Remove unused inline function ixgbe_irq_disable_queues commit b5f69ccf6765 ("ixgbe: avoid bringing rings up/down as macvlans are added/removed") left behind this, remove it. Signed-off-by: YueHaibing --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 29 --- 1 file changed, 29 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH net-next] ixgbe: fix signed-integer-overflow warning
-Original Message- From: Intel-wired-lan On Behalf Of Xie XiuQi Sent: Monday, May 4, 2020 7:45 PM To: Kirsher, Jeffrey T ; da...@davemloft.net Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux-kernel@vger.kernel.org Subject: [Intel-wired-lan] [PATCH net-next] ixgbe: fix signed-integer-overflow warning 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 --- drivers/net/ethernet/intel/ixgbe/ixgbe_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH 1/1] ixgbe: protect TX timestamping from API misuse
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Manjunath Patil > Sent: Saturday, October 5, 2019 8:20 AM > To: Kirsher, Jeffrey T ; da...@davemloft.net; > intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: manjunath.b.pa...@oracle.com; christophe.jail...@wanadoo.fr; > csprad...@google.com > Subject: [Intel-wired-lan] [PATCH 1/1] ixgbe: protect TX timestamping from > API misuse > > HW timestamping can only be requested for a packet if the NIC is first setup > via ioctl(SIOCSHWTSTAMP). If this step was skipped, then the ixgbe driver > still allowed TX packets to request HW timestamping. In this situation, we see > 'clearing Tx Timestamp hang' noise in the log. > > Fix this by checking that the NIC is configured for HW TX timestamping before > accepting a HW TX timestamping request. > > similar-to: > (26bd4e2 igb: protect TX timestamping from API misuse) > (0a6f2f0 igb: Fix a test with HWTSTAMP_TX_ON) > > Signed-off-by: Manjunath Patil > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH] i40e: prevent memory leak in i40e_setup_macvlans
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Navid Emamdoost > Sent: Wednesday, September 25, 2019 8:49 AM > Cc: net...@vger.kernel.org; k...@umn.edu; linux-kernel@vger.kernel.org; > emamd...@umn.edu; intel-wired-...@lists.osuosl.org; > smcca...@umn.edu; David S. Miller ; Navid > Emamdoost > Subject: [Intel-wired-lan] [PATCH] i40e: prevent memory leak in > i40e_setup_macvlans > > In i40e_setup_macvlans if i40e_setup_channel fails the allocated memory for > ch should be released. > > Signed-off-by: Navid Emamdoost > --- > drivers/net/ethernet/intel/i40e/i40e_main.c | 1 + > 1 file changed, 1 insertion(+) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH] net/ixgbevf: make array api static const, makes object smaller
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Colin King > Sent: Friday, September 6, 2019 4:34 AM > To: Kirsher, Jeffrey T ; David S . Miller > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org > Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH] net/ixgbevf: make array api static const, > makes object smaller > > From: Colin Ian King > > Don't populate the array api on the stack but instead make it static const. > Makes the object code smaller by 58 bytes. > > Before: >text data bss dec hex filename > 82969 9763 256 92988 16b3c ixgbevf/ixgbevf_main.o > > After: >text data bss dec hex filename > 82815 9859 256 92930 16b02 ixgbevf/ixgbevf_main.o > > (gcc version 9.2.1, amd64) > > Signed-off-by: Colin Ian King > --- > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 14 -- > 1 file changed, 8 insertions(+), 6 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH] net: ixgbe: fix memory leaks
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Wenwen Wang > Sent: Sunday, August 11, 2019 1:08 PM > To: Wenwen Wang > Cc: open list:NETWORKING DRIVERS ; moderated > list:INTEL ETHERNET DRIVERS ; open list > ; David S. Miller > Subject: [Intel-wired-lan] [PATCH] net: ixgbe: fix memory leaks > > In ixgbe_configure_clsu32(), 'jump', 'input', and 'mask' are allocated through > kzalloc() respectively in a for loop body. Then, > ixgbe_clsu32_build_input() is invoked to build the input. If this process > fails, > next iteration of the for loop will be executed. However, the allocated > 'jump', 'input', and 'mask' are not deallocated on this execution path, > leading > to memory leaks. > > Signed-off-by: Wenwen Wang > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 > 1 file changed, 4 insertions(+) Tested-by: Andrew Bowers
RE: [PATCH v3 1/1] ixgbe: sync the first fragment unconditionally
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Firo Yang > Sent: Wednesday, August 7, 2019 9:04 PM > To: net...@vger.kernel.org > Cc: maciejromanfijalkow...@gmail.com; Firo Yang ; > linux-kernel@vger.kernel.org; intel-wired-...@lists.osuosl.org; > jian.w@oracle.com; alexander.h.du...@linux.intel.com; > da...@davemloft.net > Subject: [Intel-wired-lan] [PATCH v3 1/1] ixgbe: sync the first fragment > unconditionally > > In Xen environment, if Xen-swiotlb is enabled, ixgbe driver could possibly > allocate a page, DMA memory buffer, for the first fragment which is not > suitable for Xen-swiotlb to do DMA operations. > Xen-swiotlb have to internally allocate another page for doing DMA > operations. This mechanism requires syncing the data from the internal page > to the page which ixgbe sends to upper network stack. However, since > commit f3213d932173 ("ixgbe: Update driver to make use of DMA attributes > in Rx path"), the unmap operation is performed with > DMA_ATTR_SKIP_CPU_SYNC. As a result, the sync is not performed. > Since the sync isn't performed, the upper network stack could receive a > incomplete network packet. By incomplete, it means the linear data on the > first fragment(between skb->head and skb->end) is invalid. So we have to > copy the data from the internal xen-swiotlb page to the page which ixgbe > sends to upper network stack through the sync operation. > > More details from Alexander Duyck: > Specifically since we are mapping the frame with > DMA_ATTR_SKIP_CPU_SYNC we have to unmap with that as well. As a result > a sync is not performed on an unmap and must be done manually as we > skipped it for the first frag. As such we need to always sync before possibly > performing a page unmap operation. > > Fixes: f3213d932173 ("ixgbe: Update driver to make use of DMA attributes in > Rx path") > Reviewed-by: Alexander Duyck > Signed-off-by: Firo Yang > --- > Changes from v2: > * Added details on the problem caused by skipping the sync. > * Added more explanation from Alexander Duyck. > > Changes from v1: > * Imporved the patch description. > * Added Reviewed-by: and Fixes: as suggested by Alexander Duyck. > > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 +--- > 1 file changed, 9 insertions(+), 7 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH][net-next] ice: fix potential infinite loop
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Colin King > Sent: Friday, August 2, 2019 8:52 AM > To: Kirsher, Jeffrey T ; David S . Miller > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org > Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH][net-next] ice: fix potential infinite loop > > From: Colin Ian King > > The loop counter of a for-loop is a u8 however this is being compared to an > int upper bound and this can lead to an infinite loop if the upper bound is > greater than 255 since the loop counter will wrap back to zero. Fix this > potential issue by making the loop counter an int. > > Addresses-Coverity: ("Infinite loop") > Fixes: c7aeb4d1b9bf ("ice: Disable VFs until reset is completed") > Signed-off-by: Colin Ian King > --- > drivers/net/ethernet/intel/ice/ice_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH 2/2] ixgbe: Use refcount_t for refcount
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Chuhong Yuan > Sent: Friday, August 2, 2019 3:55 AM > Cc: net...@vger.kernel.org; Chuhong Yuan ; linux- > ker...@vger.kernel.org; intel-wired-...@lists.osuosl.org; David S . Miller > > Subject: [Intel-wired-lan] [PATCH 2/2] ixgbe: Use refcount_t for refcount > > refcount_t is better for reference counters since its implementation can > prevent overflows. > So convert atomic_t ref counters to refcount_t. > > Also convert refcount from 0-based to 1-based. > > This patch depends on PATCH 1/2. > > Signed-off-by: Chuhong Yuan > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 6 +++--- > drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.h | 2 +- > 2 files changed, 4 insertions(+), 4 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH 1/2] ixgbe: Explicitly initialize reference count to 0
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Chuhong Yuan > Sent: Friday, August 2, 2019 3:55 AM > Cc: net...@vger.kernel.org; Chuhong Yuan ; linux- > ker...@vger.kernel.org; intel-wired-...@lists.osuosl.org; David S . Miller > > Subject: [Intel-wired-lan] [PATCH 1/2] ixgbe: Explicitly initialize reference > count to 0 > > The driver does not explicitly call atomic_set to initialize refcount to 0. > Add the call so that it will be more straight forward to convert refcount from > atomic_t to refcount_t. > > Signed-off-by: Chuhong Yuan > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 1 + > 1 file changed, 1 insertion(+) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH] i40e: reduce stack usage in i40e_set_fc
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Arnd Bergmann > Sent: Monday, July 15, 2019 5:35 AM > To: Kirsher, Jeffrey T ; David S. Miller > > Cc: Catherine Sullivan ; Dziggel, Douglas A > ; Arnd Bergmann ; > net...@vger.kernel.org; Patryk Małek ; linux- > ker...@vger.kernel.org; Azarewicz, Piotr ; > Loktionov, Aleksandr ; clang-built- > li...@googlegroups.com; intel-wired-...@lists.osuosl.org; Marczak, Piotr > > Subject: [Intel-wired-lan] [PATCH] i40e: reduce stack usage in i40e_set_fc > > The functions i40e_aq_get_phy_abilities_resp() and i40e_set_fc() both have > giant structure on the stack, which makes each one use stack frames larger > than 500 bytes. > > As clang decides one function into the other, we get a warning for exceeding > the frame size limit on 32-bit architectures: > > drivers/net/ethernet/intel/i40e/i40e_common.c:1654:23: error: stack frame > size of 1116 bytes in function 'i40e_set_fc' [-Werror,-Wframe-larger-than=] > > When building with gcc, the inlining does not happen, but i40e_set_fc() calls > i40e_aq_get_phy_abilities_resp() anyway, so they add up on the kernel > stack just as much. > > The parts that actually use large stacks don't overlap, so make sure each one > is a separate function, and mark them as noinline_for_stack to prevent the > compilers from combining them again. > > Fixes: 0a862b43acc6 ("i40e/i40evf: Add module_types and > update_link_info") > Signed-off-by: Arnd Bergmann > --- > drivers/net/ethernet/intel/i40e/i40e_common.c | 91 +++ > 1 file changed, 51 insertions(+), 40 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH net-next] iavf: remove unused debug function iavf_debug_d
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of YueHaibing > Sent: Monday, July 1, 2019 11:20 PM > To: Kirsher, Jeffrey T ; da...@davemloft.net; > intel-wired-...@lists.osuosl.org > Cc: net...@vger.kernel.org; YueHaibing ; linux- > ker...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH net-next] iavf: remove unused debug > function iavf_debug_d > > There is no caller of function iavf_debug_d() in tree since commit > 75051ce4c5d8 ("iavf: Fix up debug print macro"), so it can be removed. > > Reported-by: Hulk Robot > Signed-off-by: YueHaibing > --- > drivers/net/ethernet/intel/iavf/iavf_main.c | 22 -- > 1 file changed, 22 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH][net-next] iavf: fix dereference of null rx_buffer pointer
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Colin King > Sent: Wednesday, June 19, 2019 7:31 AM > To: Kirsher, Jeffrey T ; David S . Miller > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org > Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH][net-next] iavf: fix dereference of null > rx_buffer pointer > > From: Colin Ian King > > A recent commit efa14c3985828d ("iavf: allow null RX descriptors") added a > null pointer sanity check on rx_buffer, however, rx_buffer is being > dereferenced before that check, which implies a null pointer dereference > bug can potentially occur. Fix this by only dereferencing rx_buffer until > after > the null pointer check. > > Addresses-Coverity: ("Dereference before null check") > Signed-off-by: Colin Ian King > --- > drivers/net/ethernet/intel/iavf/iavf_txrx.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH] ixgbe: Avoid NULL pointer dereference with VF on non-IPsec hw
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of dann frazier > Sent: Wednesday, May 22, 2019 4:23 PM > To: Kirsher, Jeffrey T ; David S. Miller > ; Shannon Nelson > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- > ker...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH] ixgbe: Avoid NULL pointer dereference > with VF on non-IPsec hw > > An ipsec structure will not be allocated if the hardware does not support > offload. Fixes the following Oops: > > [ 191.045452] Unable to handle kernel NULL pointer dereference at virtual > address [ 191.054232] Mem abort info: > [ 191.057014] ESR = 0x9604 > [ 191.060057] Exception class = DABT (current EL), IL = 32 bits > [ 191.065963] SET = 0, FnV = 0 > [ 191.069004] EA = 0, S1PTW = 0 > [ 191.072132] Data abort info: > [ 191.074999] ISV = 0, ISS = 0x0004 > [ 191.078822] CM = 0, WnR = 0 > [ 191.081780] user pgtable: 4k pages, 48-bit VAs, pgdp = 43d9e467 [ > 191.088382] [] pgd= [ 191.093252] > Internal error: Oops: 9604 [#1] SMP [ 191.098119] Modules linked in: > vhost_net vhost tap vfio_pci vfio_virqfd vfio_iommu_type1 vfio > xt_CHECKSUM iptable_mangle ipt_MASQUERADE iptable_nat nf_nat_ipv4 > nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 > ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter devlink > ebtables ip6table_filter ip6_tables iptable_filter bpfilter ipmi_ssif > nls_iso8859_1 input_leds joydev ipmi_si hns_roce_hw_v2 ipmi_devintf > hns_roce ipmi_msghandler cppc_cpufreq sch_fq_codel ib_iser rdma_cm > iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi > ip_tables x_tables autofs4 ses enclosure btrfs zstd_compress raid10 raid456 > async_raid6_recov async_memcpy async_pq async_xor async_tx xor > hid_generic usbhid hid raid6_pq libcrc32c raid1 raid0 multipath linear ixgbevf > hibmc_drm ttm [ 191.168607] drm_kms_helper aes_ce_blk aes_ce_cipher > syscopyarea crct10dif_ce sysfillrect ghash_ce qla2xxx sysimgblt sha2_ce > sha256_arm64 hisi_sas_v3_hw fb_sys_fops sha1_ce uas nvme_fc mpt3sas > ixgbe drm hisi_sas_main nvme_fabrics usb_storage hclge scsi_transport_fc > ahci libsas hnae3 raid_class libahci xfrm_algo scsi_transport_sas mdio > aes_neon_bs aes_neon_blk crypto_simd cryptd aes_arm64 [ 191.202952] > CPU: 94 PID: 0 Comm: swapper/94 Not tainted 4.19.0-rc1+ #11 [ 191.209553] > Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.20.01 > 04/26/2019 [ 191.218064] pstate: 20400089 (nzCv daIf +PAN -UAO) [ > 191.222873] pc : ixgbe_ipsec_vf_clear+0x60/0xd0 [ixgbe] [ 191.228093] lr : > ixgbe_msg_task+0x2d0/0x1088 [ixgbe] [ 191.233044] sp : 09b3bcd0 [ > 191.236346] x29: 09b3bcd0 x28: [ 191.241647] x27: > 09628000 x26: [ 191.246946] x25: 803f652d7600 > x24: 0004 [ 191.252246] x23: 803f6a718900 x22: > [ 191.257546] x21: x20: > [ 191.262845] x19: x18: > [ 191.268144] x17: x16: > [ 191.273443] x15: x14: > 00010026 [ 191.278742] x13: 00010025 x12: > 8a5f7fbe0df0 [ 191.284042] x11: 0001000b x10: > 0040 [ 191.289341] x9 : 1100 x8 : 803f6a824fd8 > [ 191.294640] x7 : 803f6a825098 x6 : 0001 [ 191.299939] x5 : > 00f0ffc0 x4 : [ 191.305238] x3 : 28c0 x2 > : 803f652d7600 [ 191.310538] x1 : x0 : 00f205f0 > [ > 191.315838] Process swapper/94 (pid: 0, stack limit = 0xaddfed5a) [ > 191.322613] Call trace: > [ 191.325055] ixgbe_ipsec_vf_clear+0x60/0xd0 [ixgbe] [ 191.329927] > ixgbe_msg_task+0x2d0/0x1088 [ixgbe] [ 191.334536] > ixgbe_msix_other+0x274/0x330 [ixgbe] [ 191.339233] > __handle_irq_event_percpu+0x78/0x270 > [ 191.343924] handle_irq_event_percpu+0x40/0x98 [ 191.348355] > handle_irq_event+0x50/0xa8 [ 191.352180] handle_fasteoi_irq+0xbc/0x148 > [ 191.356263] generic_handle_irq+0x34/0x50 [ 191.360259] > __handle_domain_irq+0x68/0xc0 [ 191.364343] gic_handle_irq+0x84/0x180 > [ 191.368079] el1_irq+0xe8/0x180 [ 191.371208] arch_cpu_idle+0x30/0x1a8 > [ 191.374860] do_idle+0x1dc/0x2a0 [ 191.378077] > cpu_startup_entry+0x2c/0x30 [ 191.381988] > secondary_start_kernel+0x150/0x1e0 > [ 191.386506] Code: 6b15003f 54000320 f1404a9f 5460 (79400260) > > Fixes: eda0333ac2930 ("ixgbe: add VF IPsec management") > Signed-off-by: dann frazier > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 3 +++ > 1 file changed, 3 insertions(+) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH][next][V2] ixgbe: fix potential u32 overflow on shift
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Colin King > Sent: Friday, June 7, 2019 11:19 AM > To: Keller, Jacob E ; Kirsher, Jeffrey T > ; David S . Miller ; > intel-wired-...@lists.osuosl.org; net...@vger.kernel.org > Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH][next][V2] ixgbe: fix potential u32 > overflow on shift > > From: Colin Ian King > > The u32 variable rem is being shifted using u32 arithmetic however it is being > passed to div_u64 that expects the expression to be a u64. > The 32 bit shift may potentially overflow, so cast rem to a u64 before > shifting > to avoid this. Also remove comment about overflow. > > Addresses-Coverity: ("Unintentional integer overflow") > Fixes: cd4583206990 ("ixgbe: implement support for SDP/PPS output on X550 > hardware") > Fixes: 68d9676fc04e ("ixgbe: fix PTP SDP pin setup on X540 hardware") > Signed-off-by: Colin Ian King > --- > > V2: update comment > > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 14 -- > 1 file changed, 4 insertions(+), 10 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH][next] i40e/i40e_virtchnl_pf: Use struct_size() in kzalloc()
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Gustavo A. R. Silva > Sent: Wednesday, June 5, 2019 8:41 AM > To: Kirsher, Jeffrey T ; David S. Miller > > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- > ker...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH][next] i40e/i40e_virtchnl_pf: Use > struct_size() in kzalloc() > > One of the more common cases of allocation size calculations is finding the > size of a structure that has a zero-sized array at the end, along with memory > for some number of elements for that array. For example: > > struct virtchnl_iwarp_qvlist_info { > ... > struct virtchnl_iwarp_qv_info qv_info[1]; }; > > size = sizeof(struct virtchnl_iwarp_qvlist_info) + (sizeof(struct > virtchnl_iwarp_qv_info) * count; instance = kzalloc(size, GFP_KERNEL); > > and > > struct virtchnl_vf_resource { > ... > struct virtchnl_vsi_resource vsi_res[1]; }; > > size = sizeof(struct virtchnl_vf_resource) + sizeof(struct > virtchnl_vsi_resource) * count; instance = kzalloc(size, GFP_KERNEL); > > Instead of leaving these open-coded and prone to type mistakes, we can > now use the new struct_size() helper: > > instance = kzalloc(struct_size(instance, qv_info, count), GFP_KERNEL); > > and > > instance = kzalloc(struct_size(instance, vsi_res, count), GFP_KERNEL); > > Notice that, in the first case above, variable size is not necessary, hence > it is > removed. > > This code was detected with the help of Coccinelle. > > Signed-off-by: Gustavo A. R. Silva > --- > .../net/ethernet/intel/i40e/i40e_virtchnl_pf.c| 15 ++- > 1 file changed, 6 insertions(+), 9 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH] ixgbevf: fix possible divide by zero in ixgbevf_update_itr
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Young Xiao > Sent: Tuesday, May 28, 2019 4:58 AM > To: Kirsher, Jeffrey T ; da...@davemloft.net; > intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: Young Xiao <92siuy...@gmail.com> > Subject: [Intel-wired-lan] [PATCH] ixgbevf: fix possible divide by zero in > ixgbevf_update_itr > > The next call to ixgbevf_update_itr will continue to dynamically update ITR. > > Copy from commit bdbeefe8ea8c ("ixgbe: fix possible divide by zero in > ixgbe_update_itr") > > Signed-off-by: Young Xiao <92siuy...@gmail.com> > --- > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 3 +++ > 1 file changed, 3 insertions(+) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH][next] ixgbe: fix potential u32 overflow on shift
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Colin King > Sent: Thursday, June 6, 2019 6:11 AM > To: Keller, Jacob E ; Kirsher, Jeffrey T > ; David S . Miller ; > intel-wired-...@lists.osuosl.org; net...@vger.kernel.org > Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH][next] ixgbe: fix potential u32 overflow on > shift > > From: Colin Ian King > > The u32 variable rem is being shifted using u32 arithmetic however it is being > passed to div_u64 that expects the expression to be a u64. > The 32 bit shift may potentially overflow, so cast rem to a u64 before > shifting > to avoid this. > > Addresses-Coverity: ("Unintentional integer overflow") > Fixes: cd4583206990 ("ixgbe: implement support for SDP/PPS output on X550 > hardware") > Fixes: 68d9676fc04e ("ixgbe: fix PTP SDP pin setup on X540 hardware") > Signed-off-by: Colin Ian King > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH] iavf: Use printf instead of gnu_printf for iavf_debug_d
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Nathan Chancellor > Sent: Wednesday, January 9, 2019 8:22 PM > To: Kirsher, Jeffrey T > Cc: net...@vger.kernel.org; Nick Desaulniers ; > linux-kernel@vger.kernel.org; Miguel Ojeda > ; intel-wired-...@lists.osuosl.org; > Nathan Chancellor ; David S. Miller > > Subject: [Intel-wired-lan] [PATCH] iavf: Use printf instead of gnu_printf for > iavf_debug_d > > Clang warns: > > In file included from drivers/net/ethernet/intel/iavf/iavf_main.c:4: > In file included from drivers/net/ethernet/intel/iavf/iavf.h:37: > In file included from drivers/net/ethernet/intel/iavf/iavf_type.h:8: > drivers/net/ethernet/intel/iavf/iavf_osdep.h:49:18: warning: 'format' > attribute argument not supported: gnu_printf [-Wignored-attributes] > __attribute__ ((format(gnu_printf, 3, 4))); > ^ > 1 warning generated. > > We can convert from gnu_printf to printf without any side effects for two > reasons: > > 1. All iavf_debug instances use standard printf formats, as pointed out >by Miguel Ojeda at the below link, meaning gnu_printf is not strictly >required. > > 2. However, GCC has aliased printf to gnu_printf on Linux since at least >2010 based on git history. > >From gcc/c-family/c-format.c: > >/* Attributes such as "printf" are equivalent to those such as > "gnu_printf" unless this is overridden by a target. */ >static const target_ovr_attr gnu_target_overrides_format_attributes[] = >{ > { "gnu_printf", "printf" }, > { "gnu_scanf","scanf" }, > { "gnu_strftime", "strftime" }, > { "gnu_strfmon", "strfmon" }, > { NULL, NULL } >}; > > The mentioned override only happens on Windows (mingw32). Changing > from gnu_printf to printf is a no-op for GCC and stops Clang from warning. > > Link: https://github.com/ClangBuiltLinux/linux/issues/111 > Suggested-by: Miguel Ojeda > Signed-off-by: Nathan Chancellor > --- > drivers/net/ethernet/intel/iavf/iavf_osdep.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH] ixgbe: remove magic constant in ixgbe_reset_hw_82599()
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Jiri Kosina > Sent: Wednesday, January 2, 2019 11:21 AM > To: Kirsher, Jeffrey T > Cc: net...@vger.kernel.org; intel-wired-...@lists.osuosl.org; linux- > ker...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH] ixgbe: remove magic constant in > ixgbe_reset_hw_82599() > > From: Jiri Kosina > > ixgbe_reset_hw_82599() resets the value of hw->mac.num_rar_entries to > pre-defined value of 128. Let's get rid of that hardcoded literal, and use > IXGBE_82599_RAR_ENTRIES instead, the same way the normal initialization > path does. > > Signed-off-by: Jiri Kosina > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_82599.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH 3/8] i40e: increase indentation
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Julia Lawall > Sent: Sunday, December 30, 2018 7:53 AM > To: Kirsher, Jeffrey T > Cc: intel-wired-...@lists.osuosl.org; kernel-janit...@vger.kernel.org; David > S. Miller ; linux-kernel@vger.kernel.org; > net...@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH 3/8] i40e: increase indentation > > Convert spaces to tabs to get correct alignment. > > Found with the help of Coccinelle. > > Signed-off-by: Julia Lawall > > --- > drivers/net/ethernet/intel/i40e/i40e_main.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH] i40e: clean up several indentation issues
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Colin King > Sent: Monday, January 7, 2019 2:59 PM > To: Kirsher, Jeffrey T ; David S . Miller > ; intel-wired-...@lists.osuosl.org; > net...@vger.kernel.org > Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: [Intel-wired-lan] [PATCH] i40e: clean up several indentation issues > > From: Colin Ian King > > There are several statements that have incorrect levels of indentation, fix > these. > > Signed-off-by: Colin Ian King > --- > drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 8 > drivers/net/ethernet/intel/i40e/i40e_main.c| 6 +++--- > drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 4 ++-- > 3 files changed, 9 insertions(+), 9 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [PATCH tip/core/rcu 13/41] ethernet/intel/ixgbe: Replace synchronize_sched() with synchronize_rcu()
> -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On > Behalf Of Paul E. McKenney > Sent: Sunday, November 11, 2018 11:44 AM > To: linux-kernel@vger.kernel.org > Cc: t...@linutronix.de; David S. Miller ; > pet...@infradead.org; fweis...@gmail.com; jiangshan...@gmail.com; > j...@joshtriplett.org; rost...@goodmis.org; o...@redhat.com; > dhowe...@redhat.com; eduma...@google.com; > mathieu.desnoy...@efficios.com; dipan...@in.ibm.com; > j...@joelfernandes.org; intel-wired-...@lists.osuosl.org; akpm@linux- > foundation.org; Paul E. McKenney ; > mi...@kernel.org > Subject: [Intel-wired-lan] [PATCH tip/core/rcu 13/41] ethernet/intel/ixgbe: > Replace synchronize_sched() with synchronize_rcu() > > Now that synchronize_rcu() waits for preempt-disable regions of code as > well as RCU read-side critical sections, synchronize_sched() can be replaced > by synchronize_rcu(). This commit therefore makes this change. > > Signed-off-by: Paul E. McKenney > Cc: Jeff Kirsher > Cc: "David S. Miller" > Cc: > --- > drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Tested-by: Andrew Bowers
RE: [Intel-wired-lan] [BUG] 4.11.0-rc1 panic on shutdown X61s
Tested this on a Thinkpad T420i, after verifying it also has an e1000e NIC, unable to reproduce. Might be limited to that particular model/firmware version you're using, which I was not able to track down here although there is another person I could ask, might be able to come up with one yet. > -Original Message- > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On > Behalf Of l...@pengaru.com > Sent: Monday, March 13, 2017 7:41 PM > To: Brown, Aaron F > Cc: vcap...@pengaru.com; linux-...@vger.kernel.org; David Singleton > ; linux-kernel ; > khalidm ; Andy Shevchenko > ; Borislav Petkov ; intel- > wired-...@lists.osuosl.org; Bjørn Mork > Subject: Re: [Intel-wired-lan] [BUG] 4.11.0-rc1 panic on shutdown X61s > > On Tue, Mar 14, 2017 at 01:20:27AM +, Brown, Aaron F wrote: > > > Borislav Petkov writes: > > > > On Sun, Mar 12, 2017 at 03:55:08PM +0200, Andy Shevchenko wrote: > > > > > > > >> The only change that IMHO matters happened between v4.10 and > > > >> v4.11- > > > rc1 is this: > > > >> > > > >> @@ -6276,8 +6274,8 @@ static int e1000e_pm_freeze(struct device > *dev) > > > >> /* Quiesce the device without resetting the hardware */ > > > >> e1000e_down(adapter, false); > > > >> e1000_free_irq(adapter); > > > >> + e1000e_reset_interrupt_capability(adapter); > > > >> } > > > >> - e1000e_reset_interrupt_capability(adapter); > > > >> > > > >> So, it apparently misses something for the other case, like > > > >> pci_disable_msi() call or so. > > > > > > > > Well, lemme add the people from > > > > > > > > 7e54d9d063fa ("e1000e: driver trying to free already-free irq") > > > > > > > > to CC then. :-) > > > > > > Already did that a week ago: > > > https://www.spinics.net/lists/netdev/msg423379.html > > > > > > Haven't heard anything back yet. Wondering if they are waiting for > > > someone else to submit the pretty obvious revert? Don't understand > > > why that should take more than a minute to figure out. It's not > > > like they are testing these changes anyway... > > > > > > > What exact part (or parts) are we looking at (lspci|grep -i eth) that > > trigger > this? Could it be a difference in .config files? The trace says it is > falling back > to legacy interrupts, does the system continue to work and does the > network continue to function in that mode? In case it's related to user space > what is the base distro? Any other information you think can help me > reproduce the issue would be appreciated. > > > > Config attached, the machine is a Thinkpad X61s 1.8Ghz with no onboard > wireless devices (rtl8192cu usb wifi is used). > > # lspci| grep -i eth > 00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network > Connection (rev 03) > > Debian jessie amd64 is the distro. > > I'll have to get back to you on if the e1000e continues functioning, the > machine continues to function until the shutdown panic. > > There were however some occurrences of subsequent suspend/resume > cycles hanging the machine hard leaving the display off, which prompted me > to resume using > 4.10 before digging any further as it's my only system right now. > > Will try get around to testing 4.11 with 7e54d9d063fa reverted soon. > > Regards, > Vito Caputo