RE: [Intel-wired-lan] [PATCH 4/4] ixgbe/ixgbe_ethtool.c: Remove unnecessary usages of memset.

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

-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()

[Bowers, AndrewX]

-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()

[Bowers, AndrewX]

-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

[Bowers, AndrewX]

-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

[Bowers, AndrewX]

-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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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()

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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()

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

> -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()

[Bowers, AndrewX]

> -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] [PATCH tip/core/rcu 13/41] ethernet/intel/ixgbe: Replace synchronize_sched() with synchronize_rcu()

[Bowers, AndrewX]

> -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

[Bowers, AndrewX]

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

RE: [Intel-wired-lan] [BUG] 4.11.0-rc1 panic on shutdown X61s

[Bowers, AndrewX]

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