All of lore.kernel.org
 help / color / mirror / Atom feed
* [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses
@ 2018-01-22 17:00 Alice Michael
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 2/8] i40e: broadcast filters can trigger overflow promiscuous Alice Michael
                   ` (7 more replies)
  0 siblings, 8 replies; 16+ messages in thread
From: Alice Michael @ 2018-01-22 17:00 UTC (permalink / raw)
  To: intel-wired-lan

From: Mitch Williams <mitch.a.williams@intel.com>

Could a Bad Person do Bad Things to a server if they found these
addresses printed in the log? Who knows? But let's not take that risk.

Remove pointers from a bunch of printks. In some cases, I was able to
adjust the mesasge to indicate whether or not the value was null. In
others, I just removed the entire message as there was really no hope of
saving it.

Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 40 ++++----------------------
 drivers/net/ethernet/intel/i40e/i40e_main.c    | 13 ++++-----
 2 files changed, 12 insertions(+), 41 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
index e9fc51b..b829fd3 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
@@ -155,8 +155,8 @@ static void i40e_dbg_dump_vsi_seid(struct i40e_pf *pf, int seid)
 		dev_info(&pf->pdev->dev, "        vlan_features = 0x%08lx\n",
 			 (unsigned long int)nd->vlan_features);
 	}
-	dev_info(&pf->pdev->dev,
-		 "    vlgrp: & = %p\n", vsi->active_vlans);
+	dev_info(&pf->pdev->dev, "    active_vlans is %s\n",
+		 vsi->active_vlans ? "<valid>" : "<null>");
 	dev_info(&pf->pdev->dev,
 		 "    flags = 0x%08lx, netdev_registered = %i, current_netdev_flags = 0x%04x\n",
 		 vsi->flags, vsi->netdev_registered, vsi->current_netdev_flags);
@@ -270,14 +270,6 @@ static void i40e_dbg_dump_vsi_seid(struct i40e_pf *pf, int seid)
 			continue;
 
 		dev_info(&pf->pdev->dev,
-			 "    rx_rings[%i]: desc = %p\n",
-			 i, rx_ring->desc);
-		dev_info(&pf->pdev->dev,
-			 "    rx_rings[%i]: dev = %p, netdev = %p, rx_bi = %p\n",
-			 i, rx_ring->dev,
-			 rx_ring->netdev,
-			 rx_ring->rx_bi);
-		dev_info(&pf->pdev->dev,
 			 "    rx_rings[%i]: state = %lu, queue_index = %d, reg_idx = %d\n",
 			 i, *rx_ring->state,
 			 rx_ring->queue_index,
@@ -307,13 +299,8 @@ static void i40e_dbg_dump_vsi_seid(struct i40e_pf *pf, int seid)
 			 rx_ring->rx_stats.realloc_count,
 			 rx_ring->rx_stats.page_reuse_count);
 		dev_info(&pf->pdev->dev,
-			 "    rx_rings[%i]: size = %i, dma = 0x%08lx\n",
-			 i, rx_ring->size,
-			 (unsigned long int)rx_ring->dma);
-		dev_info(&pf->pdev->dev,
-			 "    rx_rings[%i]: vsi = %p, q_vector = %p\n",
-			 i, rx_ring->vsi,
-			 rx_ring->q_vector);
+			 "    rx_rings[%i]: size = %i\n",
+			 i, rx_ring->size);
 		dev_info(&pf->pdev->dev,
 			 "    rx_rings[%i]: itr_setting = %d (%s)\n",
 			 i, rx_ring->itr_setting,
@@ -326,14 +313,6 @@ static void i40e_dbg_dump_vsi_seid(struct i40e_pf *pf, int seid)
 			continue;
 
 		dev_info(&pf->pdev->dev,
-			 "    tx_rings[%i]: desc = %p\n",
-			 i, tx_ring->desc);
-		dev_info(&pf->pdev->dev,
-			 "    tx_rings[%i]: dev = %p, netdev = %p, tx_bi = %p\n",
-			 i, tx_ring->dev,
-			 tx_ring->netdev,
-			 tx_ring->tx_bi);
-		dev_info(&pf->pdev->dev,
 			 "    tx_rings[%i]: state = %lu, queue_index = %d, reg_idx = %d\n",
 			 i, *tx_ring->state,
 			 tx_ring->queue_index,
@@ -355,13 +334,8 @@ static void i40e_dbg_dump_vsi_seid(struct i40e_pf *pf, int seid)
 			 tx_ring->tx_stats.tx_busy,
 			 tx_ring->tx_stats.tx_done_old);
 		dev_info(&pf->pdev->dev,
-			 "    tx_rings[%i]: size = %i, dma = 0x%08lx\n",
-			 i, tx_ring->size,
-			 (unsigned long int)tx_ring->dma);
-		dev_info(&pf->pdev->dev,
-			 "    tx_rings[%i]: vsi = %p, q_vector = %p\n",
-			 i, tx_ring->vsi,
-			 tx_ring->q_vector);
+			 "    tx_rings[%i]: size = %i\n",
+			 i, tx_ring->size);
 		dev_info(&pf->pdev->dev,
 			 "    tx_rings[%i]: DCB tc = %d\n",
 			 i, tx_ring->dcb_tc);
@@ -466,8 +440,6 @@ static void i40e_dbg_dump_vsi_seid(struct i40e_pf *pf, int seid)
 		 vsi->info.resp_reserved[6], vsi->info.resp_reserved[7],
 		 vsi->info.resp_reserved[8], vsi->info.resp_reserved[9],
 		 vsi->info.resp_reserved[10], vsi->info.resp_reserved[11]);
-	if (vsi->back)
-		dev_info(&pf->pdev->dev, "    PF = %p\n", vsi->back);
 	dev_info(&pf->pdev->dev, "    idx = %d\n", vsi->idx);
 	dev_info(&pf->pdev->dev,
 		 "    tc_config: numtc = %d, enabled_tc = 0x%x\n",
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index fcec88d..31f1b70 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -209,8 +209,8 @@ static int i40e_get_lump(struct i40e_pf *pf, struct i40e_lump_tracking *pile,
 
 	if (!pile || needed == 0 || id >= I40E_PILE_VALID_BIT) {
 		dev_info(&pf->pdev->dev,
-			 "param err: pile=%p needed=%d id=0x%04x\n",
-			 pile, needed, id);
+			 "param err: pile=%s needed=%d id=0x%04x\n",
+			 pile ? "<valid>" : "<null>", needed, id);
 		return -EINVAL;
 	}
 
@@ -10018,18 +10018,17 @@ static int i40e_vsi_clear(struct i40e_vsi *vsi)
 
 	mutex_lock(&pf->switch_mutex);
 	if (!pf->vsi[vsi->idx]) {
-		dev_err(&pf->pdev->dev, "pf->vsi[%d] is NULL, just free vsi[%d](%p,type %d)\n",
-			vsi->idx, vsi->idx, vsi, vsi->type);
+		dev_err(&pf->pdev->dev, "pf->vsi[%d] is NULL, just free vsi[%d](type %d)\n",
+			vsi->idx, vsi->idx, vsi->type);
 		goto unlock_vsi;
 	}
 
 	if (pf->vsi[vsi->idx] != vsi) {
 		dev_err(&pf->pdev->dev,
-			"pf->vsi[%d](%p, type %d) != vsi[%d](%p,type %d): no free!\n",
+			"pf->vsi[%d](type %d) != vsi[%d](type %d): no free!\n",
 			pf->vsi[vsi->idx]->idx,
-			pf->vsi[vsi->idx],
 			pf->vsi[vsi->idx]->type,
-			vsi->idx, vsi, vsi->type);
+			vsi->idx, vsi->type);
 		goto unlock_vsi;
 	}
 
-- 
2.9.5


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 2/8] i40e: broadcast filters can trigger overflow promiscuous
  2018-01-22 17:00 [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses Alice Michael
@ 2018-01-22 17:00 ` Alice Michael
  2018-01-23 22:49   ` Bowers, AndrewX
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 3/8] i40evf: Use an iterator of the same type as the list Alice Michael
                   ` (6 subsequent siblings)
  7 siblings, 1 reply; 16+ messages in thread
From: Alice Michael @ 2018-01-22 17:00 UTC (permalink / raw)
  To: intel-wired-lan

From: Alan Brady <alan.brady@intel.com>

When adding a bunch of VLANs to all the ports on a device, it's possible
to run out of space for broadcast filters.  The driver should trigger
overflow promiscuous in this circumstance to prevent traffic from being
unexpectedly dropped.

Signed-off-by: Alan Brady <alan.brady@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 31f1b70..9e1d708 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -2170,11 +2170,13 @@ i40e_aqc_broadcast_filter(struct i40e_vsi *vsi, const char *vsi_name,
 							    NULL);
 	}
 
-	if (aq_ret)
+	if (aq_ret) {
+		set_bit(__I40E_VSI_OVERFLOW_PROMISC, vsi->state);
 		dev_warn(&vsi->back->pdev->dev,
-			 "Error %s setting broadcast promiscuous mode on %s\n",
+			 "Error %s, forcing overflow promiscuous on %s\n",
 			 i40e_aq_str(hw, hw->aq.asq_last_status),
 			 vsi_name);
+	}
 
 	return aq_ret;
 }
-- 
2.9.5


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 3/8] i40evf: Use an iterator of the same type as the list
  2018-01-22 17:00 [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses Alice Michael
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 2/8] i40e: broadcast filters can trigger overflow promiscuous Alice Michael
@ 2018-01-22 17:00 ` Alice Michael
  2018-01-23 22:50   ` Bowers, AndrewX
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 4/8] i40e: refactor promisc_changed in i40e_sync_vsi_filters Alice Michael
                   ` (5 subsequent siblings)
  7 siblings, 1 reply; 16+ messages in thread
From: Alice Michael @ 2018-01-22 17:00 UTC (permalink / raw)
  To: intel-wired-lan

From: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com>

When iterating through the linked list of vlan filters, make the
iterator the same type as that of the linked list.

Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com>
---
 drivers/net/ethernet/intel/i40evf/i40evf_main.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index f78ed62..7822607 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -1027,6 +1027,7 @@ static void i40evf_up_complete(struct i40evf_adapter *adapter)
 void i40evf_down(struct i40evf_adapter *adapter)
 {
 	struct net_device *netdev = adapter->netdev;
+	struct i40evf_vlan_filter *vlf;
 	struct i40evf_mac_filter *f;
 	struct i40evf_cloud_filter *cf;
 
@@ -1046,7 +1047,7 @@ void i40evf_down(struct i40evf_adapter *adapter)
 		f->remove = true;
 	}
 	/* remove all VLAN filters */
-	list_for_each_entry(f, &adapter->vlan_filter_list, list) {
+	list_for_each_entry(vlf, &adapter->vlan_filter_list, list) {
 		f->remove = true;
 	}
 
@@ -3853,6 +3854,7 @@ static void i40evf_remove(struct pci_dev *pdev)
 {
 	struct net_device *netdev = pci_get_drvdata(pdev);
 	struct i40evf_adapter *adapter = netdev_priv(netdev);
+	struct i40evf_vlan_filter *vlf, *vlftmp;
 	struct i40evf_mac_filter *f, *ftmp;
 	struct i40evf_cloud_filter *cf, *cftmp;
 	struct i40e_hw *hw = &adapter->hw;
@@ -3917,9 +3919,10 @@ static void i40evf_remove(struct pci_dev *pdev)
 		list_del(&f->list);
 		kfree(f);
 	}
-	list_for_each_entry_safe(f, ftmp, &adapter->vlan_filter_list, list) {
-		list_del(&f->list);
-		kfree(f);
+	list_for_each_entry_safe(vlf, vlftmp, &adapter->vlan_filter_list,
+				 list) {
+		list_del(&vlf->list);
+		kfree(vlf);
 	}
 
 	spin_unlock_bh(&adapter->mac_vlan_list_lock);
-- 
2.9.5


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 4/8] i40e: refactor promisc_changed in i40e_sync_vsi_filters
  2018-01-22 17:00 [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses Alice Michael
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 2/8] i40e: broadcast filters can trigger overflow promiscuous Alice Michael
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 3/8] i40evf: Use an iterator of the same type as the list Alice Michael
@ 2018-01-22 17:00 ` Alice Michael
  2018-01-23 22:50   ` Bowers, AndrewX
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 5/8] i40e: do not force filter failure in overflow promiscuous Alice Michael
                   ` (4 subsequent siblings)
  7 siblings, 1 reply; 16+ messages in thread
From: Alice Michael @ 2018-01-22 17:00 UTC (permalink / raw)
  To: intel-wired-lan

From: Alan Brady <alan.brady@intel.com>

This code here is quite complex and easy to screw up.  Let's see if we
can't improve the readability and maintainability a bit.  This refactors
out promisc_changed into two variables 'old_overflow' and 'new_overflow'
which makes it a bit clearer when we're concerned about when and how
overflow promiscuous is changed.  This also makes so that we no longer
need to pass a boolean pointer to i40e_aqc_add_filters.  Instead we can
simply check if we changed the overflow promiscuous flag since the
function start.

Signed-off-by: Alan Brady <alan.brady@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 42 ++++++++++++++---------------
 1 file changed, 20 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 9e1d708..315eb93 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -2109,17 +2109,16 @@ void i40e_aqc_del_filters(struct i40e_vsi *vsi, const char *vsi_name,
  * @list: the list of filters to send to firmware
  * @add_head: Position in the add hlist
  * @num_add: the number of filters to add
- * @promisc_change: set to true on exit if promiscuous mode was forced on
  *
  * Send a request to firmware via AdminQ to add a chunk of filters. Will set
- * promisc_changed to true if the firmware has run out of space for more
- * filters.
+ * __I40E_VSI_OVERFLOW_PROMISC bit in vsi->state if the firmware has run out of
+ * space for more filters.
  */
 static
 void i40e_aqc_add_filters(struct i40e_vsi *vsi, const char *vsi_name,
 			  struct i40e_aqc_add_macvlan_element_data *list,
 			  struct i40e_new_mac_filter *add_head,
-			  int num_add, bool *promisc_changed)
+			  int num_add)
 {
 	struct i40e_hw *hw = &vsi->back->hw;
 	int aq_err, fcnt;
@@ -2129,7 +2128,6 @@ void i40e_aqc_add_filters(struct i40e_vsi *vsi, const char *vsi_name,
 	fcnt = i40e_update_filter_state(num_add, list, add_head);
 
 	if (fcnt != num_add) {
-		*promisc_changed = true;
 		set_bit(__I40E_VSI_OVERFLOW_PROMISC, vsi->state);
 		dev_warn(&vsi->back->pdev->dev,
 			 "Error %s adding RX filters on %s, promiscuous mode forced on\n",
@@ -2262,9 +2260,9 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
 	struct i40e_mac_filter *f;
 	struct i40e_new_mac_filter *new, *add_head = NULL;
 	struct i40e_hw *hw = &vsi->back->hw;
+	bool old_overflow, new_overflow;
 	unsigned int failed_filters = 0;
 	unsigned int vlan_filters = 0;
-	bool promisc_changed = false;
 	char vsi_name[16] = "PF";
 	int filter_list_len = 0;
 	i40e_status aq_ret = 0;
@@ -2286,6 +2284,8 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
 		usleep_range(1000, 2000);
 	pf = vsi->back;
 
+	old_overflow = test_bit(__I40E_VSI_OVERFLOW_PROMISC, vsi->state);
+
 	if (vsi->netdev) {
 		changed_flags = vsi->current_netdev_flags ^ vsi->netdev->flags;
 		vsi->current_netdev_flags = vsi->netdev->flags;
@@ -2459,15 +2459,14 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
 			/* flush a full buffer */
 			if (num_add == filter_list_len) {
 				i40e_aqc_add_filters(vsi, vsi_name, add_list,
-						     add_head, num_add,
-						     &promisc_changed);
+						     add_head, num_add);
 				memset(add_list, 0, list_size);
 				num_add = 0;
 			}
 		}
 		if (num_add) {
 			i40e_aqc_add_filters(vsi, vsi_name, add_list, add_head,
-					     num_add, &promisc_changed);
+					     num_add);
 		}
 		/* Now move all of the filters from the temp add list back to
 		 * the VSI's list.
@@ -2496,24 +2495,16 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
 	}
 	spin_unlock_bh(&vsi->mac_filter_hash_lock);
 
-	/* If promiscuous mode has changed, we need to calculate a new
-	 * threshold for when we are safe to exit
-	 */
-	if (promisc_changed)
-		vsi->promisc_threshold = (vsi->active_filters * 3) / 4;
-
 	/* Check if we are able to exit overflow promiscuous mode. We can
 	 * safely exit if we didn't just enter, we no longer have any failed
 	 * filters, and we have reduced filters below the threshold value.
 	 */
-	if (test_bit(__I40E_VSI_OVERFLOW_PROMISC, vsi->state) &&
-	    !promisc_changed && !failed_filters &&
-	    (vsi->active_filters < vsi->promisc_threshold)) {
+	if (old_overflow && !failed_filters &&
+	    vsi->active_filters < vsi->promisc_threshold) {
 		dev_info(&pf->pdev->dev,
 			 "filter logjam cleared on %s, leaving overflow promiscuous mode\n",
 			 vsi_name);
 		clear_bit(__I40E_VSI_OVERFLOW_PROMISC, vsi->state);
-		promisc_changed = true;
 		vsi->promisc_threshold = 0;
 	}
 
@@ -2523,6 +2514,14 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
 		goto out;
 	}
 
+	new_overflow = test_bit(__I40E_VSI_OVERFLOW_PROMISC, vsi->state);
+
+	/* If we are entering overflow promiscuous, we need to calculate a new
+	 * threshold for when we are safe to exit
+	 */
+	if (!old_overflow && new_overflow)
+		vsi->promisc_threshold = (vsi->active_filters * 3) / 4;
+
 	/* check for changes in promiscuous modes */
 	if (changed_flags & IFF_ALLMULTI) {
 		bool cur_multipromisc;
@@ -2543,12 +2542,11 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
 		}
 	}
 
-	if ((changed_flags & IFF_PROMISC) || promisc_changed) {
+	if ((changed_flags & IFF_PROMISC) || old_overflow != new_overflow) {
 		bool cur_promisc;
 
 		cur_promisc = (!!(vsi->current_netdev_flags & IFF_PROMISC) ||
-			       test_bit(__I40E_VSI_OVERFLOW_PROMISC,
-					vsi->state));
+			       new_overflow);
 		aq_ret = i40e_set_promiscuous(pf, cur_promisc);
 		if (aq_ret) {
 			retval = i40e_aq_rc_to_posix(aq_ret,
-- 
2.9.5


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 5/8] i40e: do not force filter failure in overflow promiscuous
  2018-01-22 17:00 [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses Alice Michael
                   ` (2 preceding siblings ...)
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 4/8] i40e: refactor promisc_changed in i40e_sync_vsi_filters Alice Michael
@ 2018-01-22 17:00 ` Alice Michael
  2018-01-23 22:51   ` Bowers, AndrewX
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 6/8] i40e: i40e: Change ethtool check from MAC to HW flag Alice Michael
                   ` (3 subsequent siblings)
  7 siblings, 1 reply; 16+ messages in thread
From: Alice Michael @ 2018-01-22 17:00 UTC (permalink / raw)
  To: intel-wired-lan

From: Alan Brady <alan.brady@intel.com>

Broadcast filters can now cause overflow promiscuous to trigger when
adding "too many" VLANs to all the ports of a device and the driver
needs a way to exit overflow promiscuous once triggered.

Currently the driver looks to see if there are "too many" filters and/or
we have any failed filters to determine when it is safe to exit overflow
promiscuous.  If we trigger overflow promiscuous with broadcast filters,
any new filters added will be "auto-failed" until we exit overflow
promiscuous.  Since the user can't manually remove the failed broadcast
filters for VLANs (nor should we expect the user to do such), there is
no way to exit overflow promiscuous without reloading the driver.

The easiest way to do this is to remove the shortcut to "auto-fail"
filters in overflow promscuous.  If the user removes the VLANs, the
failed filters will be removed and since we're no longer "auto-failing"
new filters, we'll eventually get a good set of filters and exit
overflow promiscuous.

This has the side benefit of making filter state more explicit in that
if a filter says it's failed we know for a fact it failed and not just
assuming it will if we're in overflow promiscuous.  This is nice because
if the user removes some filters and then adds some, even if we're in
overflow promiscuous, the filter might succeed; we were just assuming it
won't because the user hasn't rectified other existing failed filters.

Signed-off-by: Alan Brady <alan.brady@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 15 +--------------
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 315eb93..357fb8f 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -1374,14 +1374,7 @@ struct i40e_mac_filter *i40e_add_filter(struct i40e_vsi *vsi,
 
 		ether_addr_copy(f->macaddr, macaddr);
 		f->vlan = vlan;
-		/* If we're in overflow promisc mode, set the state directly
-		 * to failed, so we don't bother to try sending the filter
-		 * to the hardware.
-		 */
-		if (test_bit(__I40E_VSI_OVERFLOW_PROMISC, vsi->state))
-			f->state = I40E_FILTER_FAILED;
-		else
-			f->state = I40E_FILTER_NEW;
+		f->state = I40E_FILTER_NEW;
 		INIT_HLIST_NODE(&f->hlist);
 
 		key = i40e_addr_to_hkey(macaddr);
@@ -2418,12 +2411,6 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
 
 		num_add = 0;
 		hlist_for_each_entry_safe(new, h, &tmp_add_list, hlist) {
-			if (test_bit(__I40E_VSI_OVERFLOW_PROMISC,
-				     vsi->state)) {
-				new->state = I40E_FILTER_FAILED;
-				continue;
-			}
-
 			/* handle broadcast filters by updating the broadcast
 			 * promiscuous flag instead of adding a MAC filter.
 			 */
-- 
2.9.5


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 6/8] i40e: i40e: Change ethtool check from MAC to HW flag
  2018-01-22 17:00 [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses Alice Michael
                   ` (3 preceding siblings ...)
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 5/8] i40e: do not force filter failure in overflow promiscuous Alice Michael
@ 2018-01-22 17:00 ` Alice Michael
  2018-01-23 22:52   ` Bowers, AndrewX
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 7/8] i40evf: use __dev_[um]c_sync routines in .set_rx_mode Alice Michael
                   ` (2 subsequent siblings)
  7 siblings, 1 reply; 16+ messages in thread
From: Alice Michael @ 2018-01-22 17:00 UTC (permalink / raw)
  To: intel-wired-lan

From: Dave Ertman <david.m.ertman@intel.com>

The MAC, FW Version and NPAR check used to determine
if shutting off the FW LLDP engine is supported is not
using the usual feature check mechanism.

This patch fixes the problem by moving the feature check
to i40e_sw_init in order to set a flag in pf->hw_features
that ethtool will use for priv_flags disable operation.

Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e.h         |  1 +
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 12 ++----------
 drivers/net/ethernet/intel/i40e/i40e_main.c    | 10 ++++++++++
 3 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h
index 4b81a18..36d9401 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -507,6 +507,7 @@ struct i40e_pf {
 #define I40E_HW_STOP_FW_LLDP			BIT(16)
 #define I40E_HW_PORT_ID_VALID			BIT(17)
 #define I40E_HW_RESTART_AUTONEG			BIT(18)
+#define I40E_HW_STOPPABLE_FW_LLDP		BIT(19)
 
 	u64 flags;
 #define I40E_FLAG_RX_CSUM_ENABLED		BIT_ULL(0)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index abc057c..c3e4767 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -4428,17 +4428,9 @@ static int i40e_set_priv_flags(struct net_device *dev, u32 flags)
 	 * unsupported FW verions.
 	 */
 	if (changed_flags & I40E_FLAG_DISABLE_FW_LLDP) {
-		if (pf->hw.func_caps.npar_enable) {
+		if (!(pf->hw_features & I40E_HW_STOPPABLE_FW_LLDP)) {
 			dev_warn(&pf->pdev->dev,
-				 "Unable to change FW LLDP if NPAR active\n");
-			return -EOPNOTSUPP;
-		}
-
-		if (pf->hw.aq.api_maj_ver < 1 ||
-		    (pf->hw.aq.api_maj_ver == 1 &&
-		     pf->hw.aq.api_min_ver < 7)) {
-			dev_warn(&pf->pdev->dev,
-				 "FW ver does not support changing FW LLDP\n");
+				 "Device does not support changing FW LLDP\n");
 			return -EOPNOTSUPP;
 		}
 	}
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 357fb8f..7e7296a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -11153,6 +11153,16 @@ static int i40e_sw_init(struct i40e_pf *pf)
 		/* IWARP needs one extra vector for CQP just like MISC.*/
 		pf->num_iwarp_msix = (int)num_online_cpus() + 1;
 	}
+	/* Stopping the FW LLDP engine is only supported on the
+	 * XL710 with a FW ver >= 1.7.  Also, stopping FW LLDP
+	 * engine is not supported if NPAR is functioning on this
+	 * part
+	 */
+	if (pf->hw.mac.type == I40E_MAC_XL710 &&
+	    !pf->hw.func_caps.npar_enable &&
+	    (pf->hw.aq.api_maj_ver > 1 ||
+	     (pf->hw.aq.api_maj_ver == 1 && pf->hw.aq.api_min_ver > 6)))
+		pf->hw_features |= I40E_HW_STOPPABLE_FW_LLDP;
 
 #ifdef CONFIG_PCI_IOV
 	if (pf->hw.func_caps.num_vfs && pf->hw.partition_id == 1) {
-- 
2.9.5


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 7/8] i40evf: use __dev_[um]c_sync routines in .set_rx_mode
  2018-01-22 17:00 [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses Alice Michael
                   ` (4 preceding siblings ...)
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 6/8] i40e: i40e: Change ethtool check from MAC to HW flag Alice Michael
@ 2018-01-22 17:00 ` Alice Michael
  2018-01-23 22:53   ` Bowers, AndrewX
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 8/8] i40evf: Make VF reset warning message more clear Alice Michael
  2018-01-23 22:48 ` [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses Bowers, AndrewX
  7 siblings, 1 reply; 16+ messages in thread
From: Alice Michael @ 2018-01-22 17:00 UTC (permalink / raw)
  To: intel-wired-lan

From: Jacob Keller <jacob.e.keller@intel.com>

Similar to changes done to the PF driver in commit 6622f5cdbaf3 ("i40e:
make use of __dev_uc_sync and __dev_mc_sync"), replace our
home-rolled method for updating the internal status of MAC filters with
__dev_uc_sync and __dev_mc_sync.

These new functions use internal state within the netdev struct in order
to efficiently break the question of "which filters in this list need to
be added or removed" into singular "add this filter" and "delete this
filter" requests.

This vastly improves our handling of .set_rx_mode especially with large
number of MAC filters being added to the device, and even results in
a simpler .set_rx_mode handler.

Under some circumstances, such as when attached to a bridge, we may
receive a request to delete our own permanent address. Prevent deletion
of this address during i40evf_addr_unsync so that we don't accidentally
stop receiving traffic.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
 drivers/net/ethernet/intel/i40evf/i40evf_main.c | 95 +++++++++++++++----------
 1 file changed, 56 insertions(+), 39 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 7822607..8741ca74 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -785,7 +785,7 @@ static int i40evf_vlan_rx_kill_vid(struct net_device *netdev,
  **/
 static struct
 i40evf_mac_filter *i40evf_find_filter(struct i40evf_adapter *adapter,
-				      u8 *macaddr)
+				      const u8 *macaddr)
 {
 	struct i40evf_mac_filter *f;
 
@@ -808,7 +808,7 @@ i40evf_mac_filter *i40evf_find_filter(struct i40evf_adapter *adapter,
  **/
 static struct
 i40evf_mac_filter *i40evf_add_filter(struct i40evf_adapter *adapter,
-				     u8 *macaddr)
+				     const u8 *macaddr)
 {
 	struct i40evf_mac_filter *f;
 
@@ -880,50 +880,64 @@ static int i40evf_set_mac(struct net_device *netdev, void *p)
 }
 
 /**
- * i40evf_set_rx_mode - NDO callback to set the netdev filters
- * @netdev: network interface device structure
- **/
-static void i40evf_set_rx_mode(struct net_device *netdev)
+ * i40evf_addr_sync - Callback for dev_(mc|uc)_sync to add address
+ * @netdev: the netdevice
+ * @addr: address to add
+ *
+ * Called by __dev_(mc|uc)_sync when an address needs to be added. We call
+ * __dev_(uc|mc)_sync from .set_rx_mode and guarantee to hold the hash lock.
+ */
+static int i40evf_addr_sync(struct net_device *netdev, const u8 *addr)
 {
 	struct i40evf_adapter *adapter = netdev_priv(netdev);
-	struct i40evf_mac_filter *f, *ftmp;
-	struct netdev_hw_addr *uca;
-	struct netdev_hw_addr *mca;
-	struct netdev_hw_addr *ha;
-
-	/* add addr if not already in the filter list */
-	netdev_for_each_uc_addr(uca, netdev) {
-		i40evf_add_filter(adapter, uca->addr);
-	}
-	netdev_for_each_mc_addr(mca, netdev) {
-		i40evf_add_filter(adapter, mca->addr);
-	}
-
-	spin_lock_bh(&adapter->mac_vlan_list_lock);
 
-	list_for_each_entry_safe(f, ftmp, &adapter->mac_filter_list, list) {
-		netdev_for_each_mc_addr(mca, netdev)
-			if (ether_addr_equal(mca->addr, f->macaddr))
-				goto bottom_of_search_loop;
-
-		netdev_for_each_uc_addr(uca, netdev)
-			if (ether_addr_equal(uca->addr, f->macaddr))
-				goto bottom_of_search_loop;
+	if (i40evf_add_filter(adapter, addr))
+		return 0;
+	else
+		return -ENOMEM;
+}
 
-		for_each_dev_addr(netdev, ha)
-			if (ether_addr_equal(ha->addr, f->macaddr))
-				goto bottom_of_search_loop;
+/**
+ * i40evf_addr_unsync - Callback for dev_(mc|uc)_sync to remove address
+ * @netdev: the netdevice
+ * @addr: address to add
+ *
+ * Called by __dev_(mc|uc)_sync when an address needs to be removed. We call
+ * __dev_(uc|mc)_sync from .set_rx_mode and guarantee to hold the hash lock.
+ */
+static int i40evf_addr_unsync(struct net_device *netdev, const u8 *addr)
+{
+	struct i40evf_adapter *adapter = netdev_priv(netdev);
+	struct i40evf_mac_filter *f;
 
-		if (ether_addr_equal(f->macaddr, adapter->hw.mac.addr))
-			goto bottom_of_search_loop;
+	/* Under some circumstances, we might receive a request to delete
+	 * our own device address from our uc list. Because we store the
+	 * device address in the VSI's MAC/VLAN filter list, we need to ignore
+	 * such requests and not delete our device address from this list.
+	 */
+	if (ether_addr_equal(addr, netdev->dev_addr))
+		return 0;
 
-		/* f->macaddr wasn't found in uc, mc, or ha list so delete it */
+	f = i40evf_find_filter(adapter, addr);
+	if (f) {
 		f->remove = true;
 		adapter->aq_required |= I40EVF_FLAG_AQ_DEL_MAC_FILTER;
-
-bottom_of_search_loop:
-		continue;
 	}
+	return 0;
+}
+
+/**
+ * i40evf_set_rx_mode - NDO callback to set the netdev filters
+ * @netdev: network interface device structure
+ **/
+static void i40evf_set_rx_mode(struct net_device *netdev)
+{
+	struct i40evf_adapter *adapter = netdev_priv(netdev);
+
+	spin_lock_bh(&adapter->mac_vlan_list_lock);
+	__dev_uc_sync(netdev, i40evf_addr_sync, i40evf_addr_unsync);
+	__dev_mc_sync(netdev, i40evf_addr_sync, i40evf_addr_unsync);
+	spin_unlock_bh(&adapter->mac_vlan_list_lock);
 
 	if (netdev->flags & IFF_PROMISC &&
 	    !(adapter->flags & I40EVF_FLAG_PROMISC_ON))
@@ -938,8 +952,6 @@ static void i40evf_set_rx_mode(struct net_device *netdev)
 	else if (!(netdev->flags & IFF_ALLMULTI) &&
 		 adapter->flags & I40EVF_FLAG_ALLMULTI_ON)
 		adapter->aq_required |= I40EVF_FLAG_AQ_RELEASE_ALLMULTI;
-
-	spin_unlock_bh(&adapter->mac_vlan_list_lock);
 }
 
 /**
@@ -1042,10 +1054,15 @@ void i40evf_down(struct i40evf_adapter *adapter)
 
 	spin_lock_bh(&adapter->mac_vlan_list_lock);
 
+	/* clear the sync flag on all filters */
+	__dev_uc_unsync(adapter->netdev, NULL);
+	__dev_mc_unsync(adapter->netdev, NULL);
+
 	/* remove all MAC filters */
 	list_for_each_entry(f, &adapter->mac_filter_list, list) {
 		f->remove = true;
 	}
+
 	/* remove all VLAN filters */
 	list_for_each_entry(vlf, &adapter->vlan_filter_list, list) {
 		f->remove = true;
-- 
2.9.5


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 8/8] i40evf: Make VF reset warning message more clear
  2018-01-22 17:00 [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses Alice Michael
                   ` (5 preceding siblings ...)
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 7/8] i40evf: use __dev_[um]c_sync routines in .set_rx_mode Alice Michael
@ 2018-01-22 17:00 ` Alice Michael
  2018-01-23 22:54   ` Bowers, AndrewX
  2018-01-23 22:48 ` [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses Bowers, AndrewX
  7 siblings, 1 reply; 16+ messages in thread
From: Alice Michael @ 2018-01-22 17:00 UTC (permalink / raw)
  To: intel-wired-lan

From: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com>

When the PF resets the VF, the VF puts out a warning message
indicating that the VF received a reset message from the PF.
Make this message more clear so that we do not mistakenly
think that the PF is undergoing a reset.

Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com>
---
 drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c b/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c
index ff3d681..6134b61 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c
@@ -1244,7 +1244,7 @@ void i40evf_virtchnl_completion(struct i40evf_adapter *adapter,
 			i40evf_print_link_message(adapter);
 			break;
 		case VIRTCHNL_EVENT_RESET_IMPENDING:
-			dev_info(&adapter->pdev->dev, "PF reset warning received\n");
+			dev_info(&adapter->pdev->dev, "Reset warning received from the PF\n");
 			if (!(adapter->flags & I40EVF_FLAG_RESET_PENDING)) {
 				adapter->flags |= I40EVF_FLAG_RESET_PENDING;
 				dev_info(&adapter->pdev->dev, "Scheduling reset task\n");
-- 
2.9.5


^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses
  2018-01-22 17:00 [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses Alice Michael
                   ` (6 preceding siblings ...)
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 8/8] i40evf: Make VF reset warning message more clear Alice Michael
@ 2018-01-23 22:48 ` Bowers, AndrewX
  7 siblings, 0 replies; 16+ messages in thread
From: Bowers, AndrewX @ 2018-01-23 22:48 UTC (permalink / raw)
  To: intel-wired-lan

> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On
> Behalf Of Alice Michael
> Sent: Monday, January 22, 2018 9:01 AM
> To: Michael, Alice <alice.michael@intel.com>; intel-wired-
> lan at lists.osuosl.org
> Subject: [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory
> addresses
> 
> From: Mitch Williams <mitch.a.williams@intel.com>
> 
> Could a Bad Person do Bad Things to a server if they found these addresses
> printed in the log? Who knows? But let's not take that risk.
> 
> Remove pointers from a bunch of printks. In some cases, I was able to adjust
> the mesasge to indicate whether or not the value was null. In others, I just
> removed the entire message as there was really no hope of saving it.
> 
> Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 40 ++++----------------------
>  drivers/net/ethernet/intel/i40e/i40e_main.c    | 13 ++++-----
>  2 files changed, 12 insertions(+), 41 deletions(-)

Tested-by: Andrew Bowers <andrewx.bowers@intel.com>



^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 2/8] i40e: broadcast filters can trigger overflow promiscuous
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 2/8] i40e: broadcast filters can trigger overflow promiscuous Alice Michael
@ 2018-01-23 22:49   ` Bowers, AndrewX
  0 siblings, 0 replies; 16+ messages in thread
From: Bowers, AndrewX @ 2018-01-23 22:49 UTC (permalink / raw)
  To: intel-wired-lan

> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On
> Behalf Of Alice Michael
> Sent: Monday, January 22, 2018 9:01 AM
> To: Michael, Alice <alice.michael@intel.com>; intel-wired-
> lan at lists.osuosl.org
> Subject: [Intel-wired-lan] [next PATCH S86-V2 2/8] i40e: broadcast filters can
> trigger overflow promiscuous
> 
> From: Alan Brady <alan.brady@intel.com>
> 
> When adding a bunch of VLANs to all the ports on a device, it's possible to
> run out of space for broadcast filters.  The driver should trigger overflow
> promiscuous in this circumstance to prevent traffic from being unexpectedly
> dropped.
> 
> Signed-off-by: Alan Brady <alan.brady@intel.com>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_main.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

Tested-by: Andrew Bowers <andrewx.bowers@intel.com>



^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 3/8] i40evf: Use an iterator of the same type as the list
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 3/8] i40evf: Use an iterator of the same type as the list Alice Michael
@ 2018-01-23 22:50   ` Bowers, AndrewX
  0 siblings, 0 replies; 16+ messages in thread
From: Bowers, AndrewX @ 2018-01-23 22:50 UTC (permalink / raw)
  To: intel-wired-lan

> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On
> Behalf Of Alice Michael
> Sent: Monday, January 22, 2018 9:01 AM
> To: Michael, Alice <alice.michael@intel.com>; intel-wired-
> lan at lists.osuosl.org
> Subject: [Intel-wired-lan] [next PATCH S86-V2 3/8] i40evf: Use an iterator of
> the same type as the list
> 
> From: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com>
> 
> When iterating through the linked list of vlan filters, make the iterator the
> same type as that of the linked list.
> 
> Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com>
> ---
>  drivers/net/ethernet/intel/i40evf/i40evf_main.c | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)

Tested-by: Andrew Bowers <andrewx.bowers@intel.com>



^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 4/8] i40e: refactor promisc_changed in i40e_sync_vsi_filters
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 4/8] i40e: refactor promisc_changed in i40e_sync_vsi_filters Alice Michael
@ 2018-01-23 22:50   ` Bowers, AndrewX
  0 siblings, 0 replies; 16+ messages in thread
From: Bowers, AndrewX @ 2018-01-23 22:50 UTC (permalink / raw)
  To: intel-wired-lan

> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On
> Behalf Of Alice Michael
> Sent: Monday, January 22, 2018 9:01 AM
> To: Michael, Alice <alice.michael@intel.com>; intel-wired-
> lan at lists.osuosl.org
> Subject: [Intel-wired-lan] [next PATCH S86-V2 4/8] i40e: refactor
> promisc_changed in i40e_sync_vsi_filters
> 
> From: Alan Brady <alan.brady@intel.com>
> 
> This code here is quite complex and easy to screw up.  Let's see if we can't
> improve the readability and maintainability a bit.  This refactors out
> promisc_changed into two variables 'old_overflow' and 'new_overflow'
> which makes it a bit clearer when we're concerned about when and how
> overflow promiscuous is changed.  This also makes so that we no longer need
> to pass a boolean pointer to i40e_aqc_add_filters.  Instead we can simply
> check if we changed the overflow promiscuous flag since the function start.
> 
> Signed-off-by: Alan Brady <alan.brady@intel.com>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_main.c | 42 ++++++++++++++----------
> -----
>  1 file changed, 20 insertions(+), 22 deletions(-)

Tested-by: Andrew Bowers <andrewx.bowers@intel.com>



^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 5/8] i40e: do not force filter failure in overflow promiscuous
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 5/8] i40e: do not force filter failure in overflow promiscuous Alice Michael
@ 2018-01-23 22:51   ` Bowers, AndrewX
  0 siblings, 0 replies; 16+ messages in thread
From: Bowers, AndrewX @ 2018-01-23 22:51 UTC (permalink / raw)
  To: intel-wired-lan

> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On
> Behalf Of Alice Michael
> Sent: Monday, January 22, 2018 9:01 AM
> To: Michael, Alice <alice.michael@intel.com>; intel-wired-
> lan at lists.osuosl.org
> Subject: [Intel-wired-lan] [next PATCH S86-V2 5/8] i40e: do not force filter
> failure in overflow promiscuous
> 
> From: Alan Brady <alan.brady@intel.com>
> 
> Broadcast filters can now cause overflow promiscuous to trigger when adding
> "too many" VLANs to all the ports of a device and the driver needs a way to
> exit overflow promiscuous once triggered.
> 
> Currently the driver looks to see if there are "too many" filters and/or we
> have any failed filters to determine when it is safe to exit overflow
> promiscuous.  If we trigger overflow promiscuous with broadcast filters, any
> new filters added will be "auto-failed" until we exit overflow promiscuous.
> Since the user can't manually remove the failed broadcast filters for VLANs
> (nor should we expect the user to do such), there is no way to exit overflow
> promiscuous without reloading the driver.
> 
> The easiest way to do this is to remove the shortcut to "auto-fail"
> filters in overflow promscuous.  If the user removes the VLANs, the failed
> filters will be removed and since we're no longer "auto-failing"
> new filters, we'll eventually get a good set of filters and exit overflow
> promiscuous.
> 
> This has the side benefit of making filter state more explicit in that if a filter
> says it's failed we know for a fact it failed and not just assuming it will if we're
> in overflow promiscuous.  This is nice because if the user removes some
> filters and then adds some, even if we're in overflow promiscuous, the filter
> might succeed; we were just assuming it won't because the user hasn't
> rectified other existing failed filters.
> 
> Signed-off-by: Alan Brady <alan.brady@intel.com>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_main.c | 15 +--------------
>  1 file changed, 1 insertion(+), 14 deletions(-)


Tested-by: Andrew Bowers <andrewx.bowers@intel.com>



^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 6/8] i40e: i40e: Change ethtool check from MAC to HW flag
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 6/8] i40e: i40e: Change ethtool check from MAC to HW flag Alice Michael
@ 2018-01-23 22:52   ` Bowers, AndrewX
  0 siblings, 0 replies; 16+ messages in thread
From: Bowers, AndrewX @ 2018-01-23 22:52 UTC (permalink / raw)
  To: intel-wired-lan

> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On
> Behalf Of Alice Michael
> Sent: Monday, January 22, 2018 9:01 AM
> To: Michael, Alice <alice.michael@intel.com>; intel-wired-
> lan at lists.osuosl.org
> Subject: [Intel-wired-lan] [next PATCH S86-V2 6/8] i40e: i40e: Change ethtool
> check from MAC to HW flag
> 
> From: Dave Ertman <david.m.ertman@intel.com>
> 
> The MAC, FW Version and NPAR check used to determine if shutting off the
> FW LLDP engine is supported is not using the usual feature check mechanism.
> 
> This patch fixes the problem by moving the feature check to i40e_sw_init in
> order to set a flag in pf->hw_features that ethtool will use for priv_flags
> disable operation.
> 
> Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
> ---
>  drivers/net/ethernet/intel/i40e/i40e.h         |  1 +
>  drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 12 ++----------
>  drivers/net/ethernet/intel/i40e/i40e_main.c    | 10 ++++++++++
>  3 files changed, 13 insertions(+), 10 deletions(-)

Tested-by: Andrew Bowers <andrewx.bowers@intel.com>



^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 7/8] i40evf: use __dev_[um]c_sync routines in .set_rx_mode
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 7/8] i40evf: use __dev_[um]c_sync routines in .set_rx_mode Alice Michael
@ 2018-01-23 22:53   ` Bowers, AndrewX
  0 siblings, 0 replies; 16+ messages in thread
From: Bowers, AndrewX @ 2018-01-23 22:53 UTC (permalink / raw)
  To: intel-wired-lan

> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On
> Behalf Of Alice Michael
> Sent: Monday, January 22, 2018 9:01 AM
> To: Michael, Alice <alice.michael@intel.com>; intel-wired-
> lan at lists.osuosl.org
> Subject: [Intel-wired-lan] [next PATCH S86-V2 7/8] i40evf: use
> __dev_[um]c_sync routines in .set_rx_mode
> 
> From: Jacob Keller <jacob.e.keller@intel.com>
> 
> Similar to changes done to the PF driver in commit 6622f5cdbaf3 ("i40e:
> make use of __dev_uc_sync and __dev_mc_sync"), replace our home-rolled
> method for updating the internal status of MAC filters with __dev_uc_sync
> and __dev_mc_sync.
> 
> These new functions use internal state within the netdev struct in order to
> efficiently break the question of "which filters in this list need to be added or
> removed" into singular "add this filter" and "delete this filter" requests.
> 
> This vastly improves our handling of .set_rx_mode especially with large
> number of MAC filters being added to the device, and even results in a
> simpler .set_rx_mode handler.
> 
> Under some circumstances, such as when attached to a bridge, we may
> receive a request to delete our own permanent address. Prevent deletion of
> this address during i40evf_addr_unsync so that we don't accidentally stop
> receiving traffic.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
>  drivers/net/ethernet/intel/i40evf/i40evf_main.c | 95 +++++++++++++++----
> ------
>  1 file changed, 56 insertions(+), 39 deletions(-)

Tested-by: Andrew Bowers <andrewx.bowers@intel.com>



^ permalink raw reply	[flat|nested] 16+ messages in thread

* [Intel-wired-lan] [next PATCH S86-V2 8/8] i40evf: Make VF reset warning message more clear
  2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 8/8] i40evf: Make VF reset warning message more clear Alice Michael
@ 2018-01-23 22:54   ` Bowers, AndrewX
  0 siblings, 0 replies; 16+ messages in thread
From: Bowers, AndrewX @ 2018-01-23 22:54 UTC (permalink / raw)
  To: intel-wired-lan

> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On
> Behalf Of Alice Michael
> Sent: Monday, January 22, 2018 9:01 AM
> To: Michael, Alice <alice.michael@intel.com>; intel-wired-
> lan at lists.osuosl.org
> Subject: [Intel-wired-lan] [next PATCH S86-V2 8/8] i40evf: Make VF reset
> warning message more clear
> 
> From: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com>
> 
> When the PF resets the VF, the VF puts out a warning message indicating
> that the VF received a reset message from the PF.
> Make this message more clear so that we do not mistakenly think that the PF
> is undergoing a reset.
> 
> Signed-off-by: Harshitha Ramamurthy <harshitha.ramamurthy@intel.com>
> ---
>  drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Tested-by: Andrew Bowers <andrewx.bowers@intel.com>



^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2018-01-23 22:54 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-22 17:00 [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses Alice Michael
2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 2/8] i40e: broadcast filters can trigger overflow promiscuous Alice Michael
2018-01-23 22:49   ` Bowers, AndrewX
2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 3/8] i40evf: Use an iterator of the same type as the list Alice Michael
2018-01-23 22:50   ` Bowers, AndrewX
2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 4/8] i40e: refactor promisc_changed in i40e_sync_vsi_filters Alice Michael
2018-01-23 22:50   ` Bowers, AndrewX
2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 5/8] i40e: do not force filter failure in overflow promiscuous Alice Michael
2018-01-23 22:51   ` Bowers, AndrewX
2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 6/8] i40e: i40e: Change ethtool check from MAC to HW flag Alice Michael
2018-01-23 22:52   ` Bowers, AndrewX
2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 7/8] i40evf: use __dev_[um]c_sync routines in .set_rx_mode Alice Michael
2018-01-23 22:53   ` Bowers, AndrewX
2018-01-22 17:00 ` [Intel-wired-lan] [next PATCH S86-V2 8/8] i40evf: Make VF reset warning message more clear Alice Michael
2018-01-23 22:54   ` Bowers, AndrewX
2018-01-23 22:48 ` [Intel-wired-lan] [next PATCH S86-V2 1/8] i40e: don't leak memory addresses Bowers, AndrewX

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.