[Intel-wired-lan] [PATCH net-next v5 0/4] igb: enable RX network flow classification

[Intel-wired-lan] [PATCH net-next v5 0/4] igb: enable RX network flow classification

[Gangfeng]

After apply this series of patches, igb driver will supports advanced
RX filter that direct receive packets by flows to different hardware
queue. Enables tight control on routing a flow in the platform.

In our product, we use the the RX traffic classification to gurantee the
PTP(ethertype is 0x88F7) packets won't be flooded by best effort packet.
PTP packets is always be processed by Linux network stack.

step 1. 
  use the ethertype filter to filter most of packet(0x0800) to HW queue;
step 2.
  Add a rule to forward the PTP packets to another HW queue

The ethtool commands and options:

-n --show-nfc
   Retrieves the receive network flow classification configurations

-N --config-nfc
   Configures the receive network flow classification classification

Change history of this patches:
Version 1:
  Split the patch to 3 patches for review;
  Save the filters and restore them after a reset;
  In ethtool command, use key word "proto" to replace "vlan-etype:
  Fix bugs
Version 2:
  Rebase the patches on the the latest dev-queue;
Version 3:
  Report a meaningful error code for misoperation;
Version 4:
  Rebase the patches on latest dev-queue;
  Update the patch description and code comments; 
Version 5:
  Rebase the patches on latest dev-queue;
  Update the patch description; 

Gangfeng Huang (4):
  igb: add support of RX network flow classification
  igb: support RX flow classification by ethertype
  igb: support RX flow classification by VLAN priority
  igb: fix error code in igb_add_ethtool_nfc_entry()

 drivers/net/ethernet/intel/igb/e1000_82575.h   |   5 +
 drivers/net/ethernet/intel/igb/e1000_defines.h |   4 +
 drivers/net/ethernet/intel/igb/e1000_regs.h    |   1 +
 drivers/net/ethernet/intel/igb/igb.h           |  53 ++++
 drivers/net/ethernet/intel/igb/igb_ethtool.c   | 345 +++++++++++++++++++++++++
 drivers/net/ethernet/intel/igb/igb_main.c      |  44 ++++
 drivers/net/ethernet/intel/igb/igb_ptp.c       |   4 +-
 7 files changed, 454 insertions(+), 2 deletions(-)

-- 
2.7.2

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

[Gangfeng]

From: Gangfeng Huang <gangfeng.huang@ni.com>

This patch is meant to allow for RX network flow classification to insert
and remove Rx filter by ethtool. Ethtool interface has it's own rules
manager

Show all filters:
$ ethtool -n eth0
4 RX rings available
Total 2 rules

Signed-off-by: Ruhao Gao <ruhao.gao@ni.com>
Signed-off-by: Gangfeng Huang <gangfeng.huang@ni.com>
---
 drivers/net/ethernet/intel/igb/igb.h         |  32 +++++
 drivers/net/ethernet/intel/igb/igb_ethtool.c | 193 +++++++++++++++++++++++++++
 drivers/net/ethernet/intel/igb/igb_main.c    |  44 ++++++
 3 files changed, 269 insertions(+)

diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index b9609af..cdc214c 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -355,6 +355,27 @@ struct hwmon_buff {
 #define IGB_N_SDP	4
 #define IGB_RETA_SIZE	128
 
+enum igb_filter_match_flags {
+	IGB_FILTER_FLAG_NONE        = 0x0,
+};
+
+#define IGB_MAX_RXNFC_FILTERS 16
+
+/* RX network flow classification data structure */
+struct igb_nfc_input {
+	/* Byte layout in order, all values with MSB first:
+	* match_flags - 1 byte
+	*/
+	u8     match_flags;
+};
+
+struct igb_nfc_filter {
+	struct hlist_node nfc_node;
+	struct igb_nfc_input filter;
+	u16 sw_idx;
+	u16 action;
+};
+
 /* board specific private data structure */
 struct igb_adapter {
 	unsigned long active_vlans[BITS_TO_LONGS(VLAN_N_VID)];
@@ -472,6 +493,12 @@ struct igb_adapter {
 	int copper_tries;
 	struct e1000_info ei;
 	u16 eee_advert;
+
+	/* RX network flow classification support */
+	struct hlist_head nfc_filter_list;
+	unsigned int nfc_filter_count;
+	/* lock for RX network flow classification filter */
+	spinlock_t nfc_lock;
 };
 
 #define IGB_FLAG_HAS_MSI		BIT(0)
@@ -594,4 +621,9 @@ static inline struct netdev_queue *txring_txq(const struct igb_ring *tx_ring)
 	return netdev_get_tx_queue(tx_ring->netdev, tx_ring->queue_index);
 }
 
+int igb_add_filter(struct igb_adapter *adapter,
+		   struct igb_nfc_filter *input);
+int igb_erase_filter(struct igb_adapter *adapter,
+		     struct igb_nfc_filter *input);
+
 #endif /* _IGB_H_ */
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 64e91c5..2599826 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -2431,6 +2431,48 @@ static int igb_get_ts_info(struct net_device *dev,
 	}
 }
 
+static int igb_get_ethtool_nfc_entry(struct igb_adapter *adapter,
+				     struct ethtool_rxnfc *cmd)
+{
+	struct ethtool_rx_flow_spec *fsp = &cmd->fs;
+	struct igb_nfc_filter *rule = NULL;
+
+	/* report total rule count */
+	cmd->data = IGB_MAX_RXNFC_FILTERS;
+
+	hlist_for_each_entry(rule, &adapter->nfc_filter_list, nfc_node) {
+		if (fsp->location <= rule->sw_idx)
+			break;
+	}
+
+	if (!rule || fsp->location != rule->sw_idx)
+		return -EINVAL;
+
+	return -EINVAL;
+}
+
+static int igb_get_ethtool_nfc_all(struct igb_adapter *adapter,
+				   struct ethtool_rxnfc *cmd,
+				   u32 *rule_locs)
+{
+	struct igb_nfc_filter *rule;
+	int cnt = 0;
+
+	/* report total rule count */
+	cmd->data = IGB_MAX_RXNFC_FILTERS;
+
+	hlist_for_each_entry(rule, &adapter->nfc_filter_list, nfc_node) {
+		if (cnt == cmd->rule_cnt)
+			return -EMSGSIZE;
+		rule_locs[cnt] = rule->sw_idx;
+		cnt++;
+	}
+
+	cmd->rule_cnt = cnt;
+
+	return 0;
+}
+
 static int igb_get_rss_hash_opts(struct igb_adapter *adapter,
 				 struct ethtool_rxnfc *cmd)
 {
@@ -2484,6 +2526,16 @@ static int igb_get_rxnfc(struct net_device *dev, struct ethtool_rxnfc *cmd,
 		cmd->data = adapter->num_rx_queues;
 		ret = 0;
 		break;
+	case ETHTOOL_GRXCLSRLCNT:
+		cmd->rule_cnt = adapter->nfc_filter_count;
+		ret = 0;
+		break;
+	case ETHTOOL_GRXCLSRULE:
+		ret = igb_get_ethtool_nfc_entry(adapter, cmd);
+		break;
+	case ETHTOOL_GRXCLSRLALL:
+		ret = igb_get_ethtool_nfc_all(adapter, cmd, rule_locs);
+		break;
 	case ETHTOOL_GRXFH:
 		ret = igb_get_rss_hash_opts(adapter, cmd);
 		break;
@@ -2598,6 +2650,142 @@ static int igb_set_rss_hash_opt(struct igb_adapter *adapter,
 	return 0;
 }
 
+int igb_add_filter(struct igb_adapter *adapter, struct igb_nfc_filter *input)
+{
+	return -EINVAL;
+}
+
+int igb_erase_filter(struct igb_adapter *adapter, struct igb_nfc_filter *input)
+{
+	return 0;
+}
+
+static int igb_update_ethtool_nfc_entry(struct igb_adapter *adapter,
+					struct igb_nfc_filter *input,
+					u16 sw_idx)
+{
+	struct igb_nfc_filter *rule, *parent;
+	int err = -EINVAL;
+
+	parent = NULL;
+	rule = NULL;
+
+	hlist_for_each_entry(rule, &adapter->nfc_filter_list, nfc_node) {
+		/* hash found, or no matching entry */
+		if (rule->sw_idx >= sw_idx)
+			break;
+		parent = rule;
+	}
+
+	/* if there is an old rule occupying our place remove it */
+	if (rule && (rule->sw_idx == sw_idx)) {
+		if (!input)
+			err = igb_erase_filter(adapter, rule);
+
+		hlist_del(&rule->nfc_node);
+		kfree(rule);
+		adapter->nfc_filter_count--;
+	}
+
+	/* If no input this was a delete, err should be 0 if a rule was
+	 * successfully found and removed from the list else -EINVAL
+	 */
+	if (!input)
+		return err;
+
+	/* initialize node */
+	INIT_HLIST_NODE(&input->nfc_node);
+
+	/* add filter to the list */
+	if (parent)
+		hlist_add_behind(&parent->nfc_node, &input->nfc_node);
+	else
+		hlist_add_head(&input->nfc_node, &adapter->nfc_filter_list);
+
+	/* update counts */
+	adapter->nfc_filter_count++;
+
+	return 0;
+}
+
+static int igb_add_ethtool_nfc_entry(struct igb_adapter *adapter,
+				     struct ethtool_rxnfc *cmd)
+{
+	struct net_device *netdev = adapter->netdev;
+	struct ethtool_rx_flow_spec *fsp =
+		(struct ethtool_rx_flow_spec *)&cmd->fs;
+	struct igb_nfc_filter *input, *rule;
+	int err = 0;
+
+	if (!(netdev->hw_features & NETIF_F_NTUPLE))
+		return -ENOTSUPP;
+
+	/* Don't allow programming if the action is a queue greater than
+	 * the number of online Rx queues.
+	 */
+	if ((fsp->ring_cookie == RX_CLS_FLOW_DISC) ||
+	    (fsp->ring_cookie >= adapter->num_rx_queues)) {
+		dev_err(&adapter->pdev->dev, "ethtool -N: The specified action is invalid\n");
+		return -EINVAL;
+	}
+
+	/* Don't allow indexes to exist outside of available space */
+	if (fsp->location >= IGB_MAX_RXNFC_FILTERS) {
+		dev_err(&adapter->pdev->dev, "Location out of range\n");
+		return -EINVAL;
+	}
+
+	if ((fsp->flow_type & ~FLOW_EXT) != ETHER_FLOW)
+		return -EINVAL;
+
+	input = kzalloc(sizeof(*input), GFP_KERNEL);
+	if (!input)
+		return -ENOMEM;
+
+	input->action = fsp->ring_cookie;
+	input->sw_idx = fsp->location;
+
+	spin_lock(&adapter->nfc_lock);
+
+	hlist_for_each_entry(rule, &adapter->nfc_filter_list, nfc_node) {
+		if (!memcmp(&input->filter, &rule->filter,
+			    sizeof(input->filter))) {
+			err = -EEXIST;
+			dev_err(&adapter->pdev->dev,
+				"ethtool: this filter is already set\n");
+			goto err_out_w_lock;
+		}
+	}
+
+	err = igb_add_filter(adapter, input);
+	if (err)
+		goto err_out_w_lock;
+
+	igb_update_ethtool_nfc_entry(adapter, input, input->sw_idx);
+
+	spin_unlock(&adapter->nfc_lock);
+	return 0;
+
+err_out_w_lock:
+	spin_unlock(&adapter->nfc_lock);
+	kfree(input);
+	return err;
+}
+
+static int igb_del_ethtool_nfc_entry(struct igb_adapter *adapter,
+				     struct ethtool_rxnfc *cmd)
+{
+	struct ethtool_rx_flow_spec *fsp =
+		(struct ethtool_rx_flow_spec *)&cmd->fs;
+	int err;
+
+	spin_lock(&adapter->nfc_lock);
+	err = igb_update_ethtool_nfc_entry(adapter, NULL, fsp->location);
+	spin_unlock(&adapter->nfc_lock);
+
+	return err;
+}
+
 static int igb_set_rxnfc(struct net_device *dev, struct ethtool_rxnfc *cmd)
 {
 	struct igb_adapter *adapter = netdev_priv(dev);
@@ -2607,6 +2795,11 @@ static int igb_set_rxnfc(struct net_device *dev, struct ethtool_rxnfc *cmd)
 	case ETHTOOL_SRXFH:
 		ret = igb_set_rss_hash_opt(adapter, cmd);
 		break;
+	case ETHTOOL_SRXCLSRLINS:
+		ret = igb_add_ethtool_nfc_entry(adapter, cmd);
+		break;
+	case ETHTOOL_SRXCLSRLDEL:
+		ret = igb_del_ethtool_nfc_entry(adapter, cmd);
 	default:
 		break;
 	}
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 2172769..18acf06 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -176,6 +176,8 @@ static int igb_ndo_set_vf_spoofchk(struct net_device *netdev, int vf,
 static int igb_ndo_get_vf_config(struct net_device *netdev, int vf,
 				 struct ifla_vf_info *ivi);
 static void igb_check_vf_rate_limit(struct igb_adapter *);
+static void igb_nfc_filter_exit(struct igb_adapter *adapter);
+static void igb_nfc_filter_restore(struct igb_adapter *adapter);
 
 #ifdef CONFIG_PCI_IOV
 static int igb_vf_configure(struct igb_adapter *adapter, int vf);
@@ -1611,6 +1613,7 @@ static void igb_configure(struct igb_adapter *adapter)
 	igb_setup_mrqc(adapter);
 	igb_setup_rctl(adapter);
 
+	igb_nfc_filter_restore(adapter);
 	igb_configure_tx(adapter);
 	igb_configure_rx(adapter);
 
@@ -2058,6 +2061,21 @@ static int igb_set_features(struct net_device *netdev,
 	if (!(changed & (NETIF_F_RXALL | NETIF_F_NTUPLE)))
 		return 0;
 
+	if (!(features & NETIF_F_NTUPLE)) {
+		struct hlist_node *node2;
+		struct igb_nfc_filter *rule;
+
+		spin_lock(&adapter->nfc_lock);
+		hlist_for_each_entry_safe(rule, node2,
+					  &adapter->nfc_filter_list, nfc_node) {
+			igb_erase_filter(adapter, rule);
+			hlist_del(&rule->nfc_node);
+			kfree(rule);
+		}
+		spin_unlock(&adapter->nfc_lock);
+		adapter->nfc_filter_count = 0;
+	}
+
 	netdev->features = features;
 
 	if (netif_running(netdev))
@@ -3243,6 +3261,8 @@ static int __igb_close(struct net_device *netdev, bool suspending)
 	igb_down(adapter);
 	igb_free_irq(adapter);
 
+	igb_nfc_filter_exit(adapter);
+
 	igb_free_all_tx_resources(adapter);
 	igb_free_all_rx_resources(adapter);
 
@@ -8306,4 +8326,28 @@ int igb_reinit_queues(struct igb_adapter *adapter)
 
 	return err;
 }
+
+static void igb_nfc_filter_exit(struct igb_adapter *adapter)
+{
+	struct igb_nfc_filter *rule;
+
+	spin_lock(&adapter->nfc_lock);
+
+	hlist_for_each_entry(rule, &adapter->nfc_filter_list, nfc_node)
+		igb_erase_filter(adapter, rule);
+
+	spin_unlock(&adapter->nfc_lock);
+}
+
+static void igb_nfc_filter_restore(struct igb_adapter *adapter)
+{
+	struct igb_nfc_filter *rule;
+
+	spin_lock(&adapter->nfc_lock);
+
+	hlist_for_each_entry(rule, &adapter->nfc_filter_list, nfc_node)
+		igb_add_filter(adapter, rule);
+
+	spin_unlock(&adapter->nfc_lock);
+}
 /* igb_main.c */
-- 
2.7.2

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On
> Behalf Of Gangfeng
> Sent: Monday, May 9, 2016 2:28 AM
> To: intel-wired-lan at lists.osuosl.org
> Cc: Gangfeng Huang <gangfeng.huang@ni.com>; Ruhao Gao
> <ruhao.gao@ni.com>
> Subject: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> network flow classification
> 
> From: Gangfeng Huang <gangfeng.huang@ni.com>
> 
> This patch is meant to allow for RX network flow classification to insert
> and remove Rx filter by ethtool. Ethtool interface has it's own rules
> manager
> 
> Show all filters:
> $ ethtool -n eth0
> 4 RX rings available
> Total 2 rules
> 
> Signed-off-by: Ruhao Gao <ruhao.gao@ni.com>
> Signed-off-by: Gangfeng Huang <gangfeng.huang@ni.com>
> ---
>  drivers/net/ethernet/intel/igb/igb.h         |  32 +++++
>  drivers/net/ethernet/intel/igb/igb_ethtool.c | 193
> +++++++++++++++++++++++++++
>  drivers/net/ethernet/intel/igb/igb_main.c    |  44 ++++++
>  3 files changed, 269 insertions(+)

This patch is causing 3/4 of my regression systems to fail.  Driver load seems normal, but applying an IP address via ifconfig causes the following splat in dmesg and /var/log/messages:
----------------------------------------------
May 16 14:37:50 u1486 kernel: Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.0b 11/06/2013
May 16 14:37:50 u1486 kernel: 0000000000000000 ffff880849ad3938 ffffffff813373d7 0000000000000007
May 16 14:37:50 u1486 kernel: 0000000000000006 0000000000000000 ffff88085c2f6770 ffff880849ad3a58
May 16 14:37:50 u1486 kernel: ffffffff810c4e13 ffff880849ad39f8 0000000000000005 0000000000000000
May 16 14:37:50 u1486 kernel: Call Trace:
May 16 14:37:50 u1486 kernel: [<ffffffff813373d7>] dump_stack+0x6b/0xa4
May 16 14:37:50 u1486 kernel: [<ffffffff810c4e13>] register_lock_class+0x523/0x5c0
May 16 14:37:50 u1486 kernel: [<ffffffff8136644b>] ? check_preemption_disabled+0x1b/0x110
May 16 14:37:50 u1486 kernel: [<ffffffff811f5655>] ? kfree+0x1a5/0x3a0
May 16 14:37:50 u1486 kernel: [<ffffffff81366553>] ? __this_cpu_preempt_check+0x13/0x20
May 16 14:37:50 u1486 kernel: [<ffffffff810c7ae0>] __lock_acquire+0x80/0x5d0
May 16 14:37:50 u1486 kernel: [<ffffffff811f83f5>] ? __kmalloc+0x265/0x3a0
May 16 14:37:50 u1486 kernel: [<ffffffffa051864f>] ? kzalloc+0xf/0x20 [igb]
May 16 14:37:50 u1486 kernel: [<ffffffff810c80fa>] lock_acquire+0xca/0x240
May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>] ? igb_configure+0xaf/0x1d0 [igb]
May 16 14:37:50 u1486 kernel: [<ffffffff815b958b>] ? netdev_rss_key_fill+0x5b/0xa0
May 16 14:37:50 u1486 kernel: [<ffffffffa052dfb9>] ? igb_vfta_set+0x189/0x1f0 [igb]
May 16 14:37:50 u1486 kernel: [<ffffffff816a8930>] _raw_spin_lock+0x40/0x80
May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>] ? igb_configure+0xaf/0x1d0 [igb]
May 16 14:37:50 u1486 kernel: [<ffffffffa051bf62>] ? igb_setup_rctl+0x22/0xb0 [igb]
May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>] igb_configure+0xaf/0x1d0 [igb]
May 16 14:37:50 u1486 kernel: [<ffffffffa052408d>] __igb_open+0xfd/0x300 [igb]
May 16 14:37:50 u1486 kernel: [<ffffffff815ab260>] ? call_netdevice_notifiers_info+0x40/0x70
May 16 14:37:50 u1486 kernel: [<ffffffffa0524420>] igb_open+0x10/0x20 [igb]
May 16 14:37:50 u1486 kernel: [<ffffffff815ac7f8>] __dev_open+0xb8/0x110
May 16 14:37:50 u1486 kernel: [<ffffffff815ac5fc>] __dev_change_flags+0xac/0x180
May 16 14:37:50 u1486 kernel: [<ffffffff815ac700>] dev_change_flags+0x30/0x70
May 16 14:37:50 u1486 kernel: [<ffffffff815c6685>] ? lockdep_rtnl_is_held+0x15/0x20
May 16 14:37:50 u1486 kernel: [<ffffffff816403a5>] devinet_ioctl+0x5b5/0x620
May 16 14:37:50 u1486 kernel: [<ffffffff81156660>] ? trace_buffer_unlock_commit+0x60/0x80
May 16 14:37:50 u1486 kernel: [<ffffffff81643033>] inet_ioctl+0x63/0x80
May 16 14:37:50 u1486 kernel: [<ffffffff8158fd60>] sock_do_ioctl+0x30/0x70
May 16 14:37:50 u1486 kernel: [<ffffffff815901b3>] sock_ioctl+0x73/0x280
May 16 14:37:50 u1486 kernel: [<ffffffff8121f678>] vfs_ioctl+0x18/0x30
May 16 14:37:50 u1486 kernel: [<ffffffff81220057>] do_vfs_ioctl+0x87/0x430
May 16 14:37:50 u1486 kernel: [<ffffffff8100297e>] ? syscall_trace_enter_phase2+0x6e/0x280
May 16 14:37:50 u1486 kernel: [<ffffffff81220492>] SyS_ioctl+0x92/0xa0
May 16 14:37:50 u1486 kernel: [<ffffffff81002fd3>] do_syscall_64+0x63/0x130
May 16 14:37:50 u1486 kernel: [<ffffffff8100201b>] ? trace_hardirqs_on_thunk+0x1b/0x1d
May 16 14:37:50 u1486 kernel: [<ffffffff816a981a>] entry_SYSCALL64_slow_path+0x25/0x25
----------------------------------------------
The system will then seem to function normally for a few minutes more then, even if left completely idle, will spew out another splat and the console freezes.  A few more minutes and another splat hits the screen, but he console is otherwise still locked up.  These later splats do not get captured to the logs.

I am seeing this on systems with a pair i350s and 82576s, a quad i354 and an i211 and pair of 82580s.  A system with a pair of 82580 ports and an i210 seems fine.

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

[Brown, Aaron F]

> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On
> Behalf Of Brown, Aaron F
> Sent: Monday, May 16, 2016 3:09 PM
> To: Gangfeng <gangfeng.huang@ni.com>; intel-wired-lan at lists.osuosl.org
> Cc: Ruhao Gao <ruhao.gao@ni.com>
> Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> network flow classification
> 
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On
> > Behalf Of Gangfeng
> > Sent: Monday, May 9, 2016 2:28 AM
> > To: intel-wired-lan at lists.osuosl.org
> > Cc: Gangfeng Huang <gangfeng.huang@ni.com>; Ruhao Gao
> > <ruhao.gao@ni.com>
> > Subject: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> > network flow classification
> >
> > From: Gangfeng Huang <gangfeng.huang@ni.com>
> >
> > This patch is meant to allow for RX network flow classification to insert
> > and remove Rx filter by ethtool. Ethtool interface has it's own rules
> > manager
> >
> > Show all filters:
> > $ ethtool -n eth0
> > 4 RX rings available
> > Total 2 rules
> >
> > Signed-off-by: Ruhao Gao <ruhao.gao@ni.com>
> > Signed-off-by: Gangfeng Huang <gangfeng.huang@ni.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb.h         |  32 +++++
> >  drivers/net/ethernet/intel/igb/igb_ethtool.c | 193
> > +++++++++++++++++++++++++++
> >  drivers/net/ethernet/intel/igb/igb_main.c    |  44 ++++++
> >  3 files changed, 269 insertions(+)
> 
> This patch is causing 3/4 of my regression systems to fail.  Driver load seems
> normal, but applying an IP address via ifconfig causes the following splat in

<snip>

> The system will then seem to function normally for a few minutes more then,
> even if left completely idle, will spew out another splat and the console
> freezes.  A few more minutes and another splat hits the screen, but he
> console is otherwise still locked up.  These later splats do not get captured to
> the logs.

This second set of splats is not related to this patch or the series.  Only the splat that follows address binding seems to be caused by this patch.  A later series of patches for igb ptp seems to be the culprit for the delayed freeze trace.

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

[Matt Porter]

On Mon, May 16, 2016 at 10:09:04PM +0000, Brown, Aaron F wrote:
> > From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org] On
> > Behalf Of Gangfeng
> > Sent: Monday, May 9, 2016 2:28 AM
> > To: intel-wired-lan at lists.osuosl.org
> > Cc: Gangfeng Huang <gangfeng.huang@ni.com>; Ruhao Gao
> > <ruhao.gao@ni.com>
> > Subject: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> > network flow classification
> > 
> > From: Gangfeng Huang <gangfeng.huang@ni.com>
> > 
> > This patch is meant to allow for RX network flow classification to insert
> > and remove Rx filter by ethtool. Ethtool interface has it's own rules
> > manager
> > 
> > Show all filters:
> > $ ethtool -n eth0
> > 4 RX rings available
> > Total 2 rules
> > 
> > Signed-off-by: Ruhao Gao <ruhao.gao@ni.com>
> > Signed-off-by: Gangfeng Huang <gangfeng.huang@ni.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb.h         |  32 +++++
> >  drivers/net/ethernet/intel/igb/igb_ethtool.c | 193
> > +++++++++++++++++++++++++++
> >  drivers/net/ethernet/intel/igb/igb_main.c    |  44 ++++++
> >  3 files changed, 269 insertions(+)
> 
> This patch is causing 3/4 of my regression systems to fail.  Driver load seems normal, but applying an IP address via ifconfig causes the following splat in dmesg and /var/log/messages:

Hi Aaron,

I'm looking at this series on current net-next and am wondering if you
saw this issue with just patch 1 applied or you meant the entire series?

I've been working with this on an i210 and haven't reproduced your
results yet either with just the (non-functional) first patch applied or
the entire series. However, I noticed you had no problems on your system
with an i210.

> ----------------------------------------------
> May 16 14:37:50 u1486 kernel: Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.0b 11/06/2013
> May 16 14:37:50 u1486 kernel: 0000000000000000 ffff880849ad3938 ffffffff813373d7 0000000000000007
> May 16 14:37:50 u1486 kernel: 0000000000000006 0000000000000000 ffff88085c2f6770 ffff880849ad3a58
> May 16 14:37:50 u1486 kernel: ffffffff810c4e13 ffff880849ad39f8 0000000000000005 0000000000000000
> May 16 14:37:50 u1486 kernel: Call Trace:
> May 16 14:37:50 u1486 kernel: [<ffffffff813373d7>] dump_stack+0x6b/0xa4
> May 16 14:37:50 u1486 kernel: [<ffffffff810c4e13>] register_lock_class+0x523/0x5c0
> May 16 14:37:50 u1486 kernel: [<ffffffff8136644b>] ? check_preemption_disabled+0x1b/0x110
> May 16 14:37:50 u1486 kernel: [<ffffffff811f5655>] ? kfree+0x1a5/0x3a0
> May 16 14:37:50 u1486 kernel: [<ffffffff81366553>] ? __this_cpu_preempt_check+0x13/0x20
> May 16 14:37:50 u1486 kernel: [<ffffffff810c7ae0>] __lock_acquire+0x80/0x5d0
> May 16 14:37:50 u1486 kernel: [<ffffffff811f83f5>] ? __kmalloc+0x265/0x3a0
> May 16 14:37:50 u1486 kernel: [<ffffffffa051864f>] ? kzalloc+0xf/0x20 [igb]
> May 16 14:37:50 u1486 kernel: [<ffffffff810c80fa>] lock_acquire+0xca/0x240
> May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>] ? igb_configure+0xaf/0x1d0 [igb]
> May 16 14:37:50 u1486 kernel: [<ffffffff815b958b>] ? netdev_rss_key_fill+0x5b/0xa0
> May 16 14:37:50 u1486 kernel: [<ffffffffa052dfb9>] ? igb_vfta_set+0x189/0x1f0 [igb]
> May 16 14:37:50 u1486 kernel: [<ffffffff816a8930>] _raw_spin_lock+0x40/0x80
> May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>] ? igb_configure+0xaf/0x1d0 [igb]
> May 16 14:37:50 u1486 kernel: [<ffffffffa051bf62>] ? igb_setup_rctl+0x22/0xb0 [igb]
> May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>] igb_configure+0xaf/0x1d0 [igb]
> May 16 14:37:50 u1486 kernel: [<ffffffffa052408d>] __igb_open+0xfd/0x300 [igb]
> May 16 14:37:50 u1486 kernel: [<ffffffff815ab260>] ? call_netdevice_notifiers_info+0x40/0x70
> May 16 14:37:50 u1486 kernel: [<ffffffffa0524420>] igb_open+0x10/0x20 [igb]
> May 16 14:37:50 u1486 kernel: [<ffffffff815ac7f8>] __dev_open+0xb8/0x110
> May 16 14:37:50 u1486 kernel: [<ffffffff815ac5fc>] __dev_change_flags+0xac/0x180
> May 16 14:37:50 u1486 kernel: [<ffffffff815ac700>] dev_change_flags+0x30/0x70
> May 16 14:37:50 u1486 kernel: [<ffffffff815c6685>] ? lockdep_rtnl_is_held+0x15/0x20
> May 16 14:37:50 u1486 kernel: [<ffffffff816403a5>] devinet_ioctl+0x5b5/0x620
> May 16 14:37:50 u1486 kernel: [<ffffffff81156660>] ? trace_buffer_unlock_commit+0x60/0x80
> May 16 14:37:50 u1486 kernel: [<ffffffff81643033>] inet_ioctl+0x63/0x80
> May 16 14:37:50 u1486 kernel: [<ffffffff8158fd60>] sock_do_ioctl+0x30/0x70
> May 16 14:37:50 u1486 kernel: [<ffffffff815901b3>] sock_ioctl+0x73/0x280
> May 16 14:37:50 u1486 kernel: [<ffffffff8121f678>] vfs_ioctl+0x18/0x30
> May 16 14:37:50 u1486 kernel: [<ffffffff81220057>] do_vfs_ioctl+0x87/0x430
> May 16 14:37:50 u1486 kernel: [<ffffffff8100297e>] ? syscall_trace_enter_phase2+0x6e/0x280
> May 16 14:37:50 u1486 kernel: [<ffffffff81220492>] SyS_ioctl+0x92/0xa0
> May 16 14:37:50 u1486 kernel: [<ffffffff81002fd3>] do_syscall_64+0x63/0x130
> May 16 14:37:50 u1486 kernel: [<ffffffff8100201b>] ? trace_hardirqs_on_thunk+0x1b/0x1d
> May 16 14:37:50 u1486 kernel: [<ffffffff816a981a>] entry_SYSCALL64_slow_path+0x25/0x25
> ----------------------------------------------

Since it's doing dump_stack in register_lock_class it appears some of
the error has been truncated before this stack trace. Can you confirm
that this is the complete output logged? By inspection, I would expect
to see one of the contextual messages from register_lock_class when it
calls dump_stack.

Also, any chance of seeing a .config for this run or a freshly
reproduced run? By inspection at least there's no obvious locking or
otherwise issues in the open path (only *filter_restore() is executed on
open and it's a mostly a NOP if this is just patch 1 applied) so I think
we need some more detailed output since you have the only system that seems
to produce this issue.

Any other details you can provide would be appreciated. I'm happy to dig
into the root cause.

Thanks,
Matt

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

[Brown, Aaron F]

> From: Matt Porter [mailto:mporter at konsulko.com]
> Sent: Wednesday, June 29, 2016 12:13 PM
> To: Brown, Aaron F <aaron.f.brown@intel.com>
> Cc: Gangfeng <gangfeng.huang@ni.com>; intel-wired-lan at lists.osuosl.org;
> Ruhao Gao <ruhao.gao@ni.com>
> Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> network flow classification
> 
> On Mon, May 16, 2016 at 10:09:04PM +0000, Brown, Aaron F wrote:
> > > From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org]
> On
> > > Behalf Of Gangfeng
> > > Sent: Monday, May 9, 2016 2:28 AM
> > > To: intel-wired-lan at lists.osuosl.org
> > > Cc: Gangfeng Huang <gangfeng.huang@ni.com>; Ruhao Gao
> > > <ruhao.gao@ni.com>
> > > Subject: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> > > network flow classification
> > >
> > > From: Gangfeng Huang <gangfeng.huang@ni.com>
> > >
> > > This patch is meant to allow for RX network flow classification to insert
> > > and remove Rx filter by ethtool. Ethtool interface has it's own rules
> > > manager
> > >
> > > Show all filters:
> > > $ ethtool -n eth0
> > > 4 RX rings available
> > > Total 2 rules
> > >
> > > Signed-off-by: Ruhao Gao <ruhao.gao@ni.com>
> > > Signed-off-by: Gangfeng Huang <gangfeng.huang@ni.com>
> > > ---
> > >  drivers/net/ethernet/intel/igb/igb.h         |  32 +++++
> > >  drivers/net/ethernet/intel/igb/igb_ethtool.c | 193
> > > +++++++++++++++++++++++++++
> > >  drivers/net/ethernet/intel/igb/igb_main.c    |  44 ++++++
> > >  3 files changed, 269 insertions(+)
> >
> > This patch is causing 3/4 of my regression systems to fail.  Driver load
> seems normal, but applying an IP address via ifconfig causes the following
> splat in dmesg and /var/log/messages:
> 
> Hi Aaron,
> 
> I'm looking at this series on current net-next and am wondering if you
> saw this issue with just patch 1 applied or you meant the entire series?

Hi Matt,

My recollection is that I saw it with just patch 1 applied.  And my procedure when I see an issue with a series is to try and isolate it to the individual patch and reply to the one in the series that triggers the issue, so I am pretty sure it was with this patch applied and the rest of the series not applied.

> 
> I've been working with this on an i210 and haven't reproduced your
> results yet either with just the (non-functional) first patch applied or
> the entire series. However, I noticed you had no problems on your system
> with an i210.

Correct, the system with an i210 included was one of the ones not affected by this.  I'm not sure if that is due to it not being a problem with the i210 or something more elusive like the system's chipset of a variation in the .config.

> 
> > ----------------------------------------------
> > May 16 14:37:50 u1486 kernel: Hardware name: Supermicro A1SAi/A1SRi,
> BIOS 1.0b 11/06/2013
> > May 16 14:37:50 u1486 kernel: 0000000000000000 ffff880849ad3938
> ffffffff813373d7 0000000000000007
> > May 16 14:37:50 u1486 kernel: 0000000000000006 0000000000000000
> ffff88085c2f6770 ffff880849ad3a58
> > May 16 14:37:50 u1486 kernel: ffffffff810c4e13 ffff880849ad39f8
> 0000000000000005 0000000000000000
> > May 16 14:37:50 u1486 kernel: Call Trace:
> > May 16 14:37:50 u1486 kernel: [<ffffffff813373d7>] dump_stack+0x6b/0xa4
> > May 16 14:37:50 u1486 kernel: [<ffffffff810c4e13>]
> register_lock_class+0x523/0x5c0
> > May 16 14:37:50 u1486 kernel: [<ffffffff8136644b>] ?
> check_preemption_disabled+0x1b/0x110
> > May 16 14:37:50 u1486 kernel: [<ffffffff811f5655>] ? kfree+0x1a5/0x3a0
> > May 16 14:37:50 u1486 kernel: [<ffffffff81366553>] ?
> __this_cpu_preempt_check+0x13/0x20
> > May 16 14:37:50 u1486 kernel: [<ffffffff810c7ae0>]
> __lock_acquire+0x80/0x5d0
> > May 16 14:37:50 u1486 kernel: [<ffffffff811f83f5>] ?
> __kmalloc+0x265/0x3a0
> > May 16 14:37:50 u1486 kernel: [<ffffffffa051864f>] ? kzalloc+0xf/0x20 [igb]
> > May 16 14:37:50 u1486 kernel: [<ffffffff810c80fa>]
> lock_acquire+0xca/0x240
> > May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>] ?
> igb_configure+0xaf/0x1d0 [igb]
> > May 16 14:37:50 u1486 kernel: [<ffffffff815b958b>] ?
> netdev_rss_key_fill+0x5b/0xa0
> > May 16 14:37:50 u1486 kernel: [<ffffffffa052dfb9>] ?
> igb_vfta_set+0x189/0x1f0 [igb]
> > May 16 14:37:50 u1486 kernel: [<ffffffff816a8930>]
> _raw_spin_lock+0x40/0x80
> > May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>] ?
> igb_configure+0xaf/0x1d0 [igb]
> > May 16 14:37:50 u1486 kernel: [<ffffffffa051bf62>] ?
> igb_setup_rctl+0x22/0xb0 [igb]
> > May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>]
> igb_configure+0xaf/0x1d0 [igb]
> > May 16 14:37:50 u1486 kernel: [<ffffffffa052408d>]
> __igb_open+0xfd/0x300 [igb]
> > May 16 14:37:50 u1486 kernel: [<ffffffff815ab260>] ?
> call_netdevice_notifiers_info+0x40/0x70
> > May 16 14:37:50 u1486 kernel: [<ffffffffa0524420>] igb_open+0x10/0x20
> [igb]
> > May 16 14:37:50 u1486 kernel: [<ffffffff815ac7f8>]
> __dev_open+0xb8/0x110
> > May 16 14:37:50 u1486 kernel: [<ffffffff815ac5fc>]
> __dev_change_flags+0xac/0x180
> > May 16 14:37:50 u1486 kernel: [<ffffffff815ac700>]
> dev_change_flags+0x30/0x70
> > May 16 14:37:50 u1486 kernel: [<ffffffff815c6685>] ?
> lockdep_rtnl_is_held+0x15/0x20
> > May 16 14:37:50 u1486 kernel: [<ffffffff816403a5>]
> devinet_ioctl+0x5b5/0x620
> > May 16 14:37:50 u1486 kernel: [<ffffffff81156660>] ?
> trace_buffer_unlock_commit+0x60/0x80
> > May 16 14:37:50 u1486 kernel: [<ffffffff81643033>] inet_ioctl+0x63/0x80
> > May 16 14:37:50 u1486 kernel: [<ffffffff8158fd60>]
> sock_do_ioctl+0x30/0x70
> > May 16 14:37:50 u1486 kernel: [<ffffffff815901b3>] sock_ioctl+0x73/0x280
> > May 16 14:37:50 u1486 kernel: [<ffffffff8121f678>] vfs_ioctl+0x18/0x30
> > May 16 14:37:50 u1486 kernel: [<ffffffff81220057>]
> do_vfs_ioctl+0x87/0x430
> > May 16 14:37:50 u1486 kernel: [<ffffffff8100297e>] ?
> syscall_trace_enter_phase2+0x6e/0x280
> > May 16 14:37:50 u1486 kernel: [<ffffffff81220492>] SyS_ioctl+0x92/0xa0
> > May 16 14:37:50 u1486 kernel: [<ffffffff81002fd3>]
> do_syscall_64+0x63/0x130
> > May 16 14:37:50 u1486 kernel: [<ffffffff8100201b>] ?
> trace_hardirqs_on_thunk+0x1b/0x1d
> > May 16 14:37:50 u1486 kernel: [<ffffffff816a981a>]
> entry_SYSCALL64_slow_path+0x25/0x25
> > ----------------------------------------------
> 
> Since it's doing dump_stack in register_lock_class it appears some of
> the error has been truncated before this stack trace. Can you confirm
> that this is the complete output logged? By inspection, I would expect
> to see one of the contextual messages from register_lock_class when it
> calls dump_stack.

I will see if I still have a copy of, or can reproduce the trace along with more of the log messages leading up to it.

> 
> Also, any chance of seeing a .config for this run or a freshly
> reproduced run? By inspection at least there's no obvious locking or
> otherwise issues in the open path (only *filter_restore() is executed on
> open and it's a mostly a NOP if this is just patch 1 applied) so I think
> we need some more detailed output since you have the only system that
> seems
> to produce this issue.

I can certainly get you a copy of the .config file on the affected systems, however, they will have changed some as the kernel gets updated frequently for tests, along with a make oldconfig pushing occasional changes in.  Assuming I can re-apply the patch to the current tree I'll try and reproduce the issue and get you copies of a .config known to be current when the issue strikes.

> 
> Any other details you can provide would be appreciated. I'm happy to dig
> into the root cause.

Only thing that immediately comes to mind is that my test systems all have multiple ports to minimize the lab space needed to get a sampling of the different parts.  I will see if I can reproduce the issue in a system with a single port.  If I remember correctly, it was a consistent issue, always appearing relatively quickly on the affected systems.
 
> 
> Thanks,
> Matt

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

[Brown, Aaron F]

> From: Brown, Aaron F
> Sent: Wednesday, June 29, 2016 1:06 PM
> To: Matt Porter <mporter@konsulko.com>
> Cc: Gangfeng <gangfeng.huang@ni.com>; intel-wired-lan at lists.osuosl.org;
> Ruhao Gao <ruhao.gao@ni.com>
> Subject: RE: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> network flow classification
> 
> > From: Matt Porter [mailto:mporter at konsulko.com]
> > Sent: Wednesday, June 29, 2016 12:13 PM
> > To: Brown, Aaron F <aaron.f.brown@intel.com>
> > Cc: Gangfeng <gangfeng.huang@ni.com>; intel-wired-lan at lists.osuosl.org;
> > Ruhao Gao <ruhao.gao@ni.com>
> > Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of
> RX
> > network flow classification
> >
> > On Mon, May 16, 2016 at 10:09:04PM +0000, Brown, Aaron F wrote:
> > > > From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org]
> > On
> > > > Behalf Of Gangfeng
> > > > Sent: Monday, May 9, 2016 2:28 AM
> > > > To: intel-wired-lan at lists.osuosl.org
> > > > Cc: Gangfeng Huang <gangfeng.huang@ni.com>; Ruhao Gao
> > > > <ruhao.gao@ni.com>
> > > > Subject: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> > > > network flow classification
> > > >
> > > > From: Gangfeng Huang <gangfeng.huang@ni.com>
> > > >
> > > > This patch is meant to allow for RX network flow classification to insert
> > > > and remove Rx filter by ethtool. Ethtool interface has it's own rules
> > > > manager
> > > >
> > > > Show all filters:
> > > > $ ethtool -n eth0
> > > > 4 RX rings available
> > > > Total 2 rules
> > > >
> > > > Signed-off-by: Ruhao Gao <ruhao.gao@ni.com>
> > > > Signed-off-by: Gangfeng Huang <gangfeng.huang@ni.com>
> > > > ---
> > > >  drivers/net/ethernet/intel/igb/igb.h         |  32 +++++
> > > >  drivers/net/ethernet/intel/igb/igb_ethtool.c | 193
> > > > +++++++++++++++++++++++++++
> > > >  drivers/net/ethernet/intel/igb/igb_main.c    |  44 ++++++
> > > >  3 files changed, 269 insertions(+)
> > >
> > > This patch is causing 3/4 of my regression systems to fail.  Driver load
> > seems normal, but applying an IP address via ifconfig causes the following
> > splat in dmesg and /var/log/messages:
> >
> > Hi Aaron,
> >
> > I'm looking at this series on current net-next and am wondering if you
> > saw this issue with just patch 1 applied or you meant the entire series?
> 
> Hi Matt,
> 
> My recollection is that I saw it with just patch 1 applied.  And my procedure
> when I see an issue with a series is to try and isolate it to the individual patch
> and reply to the one in the series that triggers the issue, so I am pretty sure it
> was with this patch applied and the rest of the series not applied.

I was able to apply this (v5 1/4) patch to a recent version of Jeff's next-queue / dev-branch (with a little fuzz) and reproduce the problem on one of the systems that was previously triggering it without any difficulty.  It does occur with just this one patch applied.  This was with the system that has an i211 and a pair of 82580 ports.  I will still try to sort out if it happens with just i211 or the pair of 82580s (leaning towards the i211 as a system with a pair of 82580s and an i210 worked fine) but have been searching for another i211 as the system in question is at the bottom of a rack with a bunch of systems stacked on top of it, making the card cage rather difficult to get to.

> 
> >
> > I've been working with this on an i210 and haven't reproduced your
> > results yet either with just the (non-functional) first patch applied or
> > the entire series. However, I noticed you had no problems on your system
> > with an i210.
> 
> Correct, the system with an i210 included was one of the ones not affected
> by this.  I'm not sure if that is due to it not being a problem with the i210 or
> something more elusive like the system's chipset of a variation in the .config.
> 
> >
> > > ----------------------------------------------
> > > May 16 14:37:50 u1486 kernel: Hardware name: Supermicro A1SAi/A1SRi,
> > BIOS 1.0b 11/06/2013
> > > May 16 14:37:50 u1486 kernel: 0000000000000000 ffff880849ad3938
> > ffffffff813373d7 0000000000000007
> > > May 16 14:37:50 u1486 kernel: 0000000000000006 0000000000000000
> > ffff88085c2f6770 ffff880849ad3a58
> > > May 16 14:37:50 u1486 kernel: ffffffff810c4e13 ffff880849ad39f8
> > 0000000000000005 0000000000000000
> > > May 16 14:37:50 u1486 kernel: Call Trace:
> > > May 16 14:37:50 u1486 kernel: [<ffffffff813373d7>]
> dump_stack+0x6b/0xa4
> > > May 16 14:37:50 u1486 kernel: [<ffffffff810c4e13>]
> > register_lock_class+0x523/0x5c0
> > > May 16 14:37:50 u1486 kernel: [<ffffffff8136644b>] ?
> > check_preemption_disabled+0x1b/0x110
> > > May 16 14:37:50 u1486 kernel: [<ffffffff811f5655>] ? kfree+0x1a5/0x3a0
> > > May 16 14:37:50 u1486 kernel: [<ffffffff81366553>] ?
> > __this_cpu_preempt_check+0x13/0x20
> > > May 16 14:37:50 u1486 kernel: [<ffffffff810c7ae0>]
> > __lock_acquire+0x80/0x5d0
> > > May 16 14:37:50 u1486 kernel: [<ffffffff811f83f5>] ?
> > __kmalloc+0x265/0x3a0
> > > May 16 14:37:50 u1486 kernel: [<ffffffffa051864f>] ? kzalloc+0xf/0x20
> [igb]
> > > May 16 14:37:50 u1486 kernel: [<ffffffff810c80fa>]
> > lock_acquire+0xca/0x240
> > > May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>] ?
> > igb_configure+0xaf/0x1d0 [igb]
> > > May 16 14:37:50 u1486 kernel: [<ffffffff815b958b>] ?
> > netdev_rss_key_fill+0x5b/0xa0
> > > May 16 14:37:50 u1486 kernel: [<ffffffffa052dfb9>] ?
> > igb_vfta_set+0x189/0x1f0 [igb]
> > > May 16 14:37:50 u1486 kernel: [<ffffffff816a8930>]
> > _raw_spin_lock+0x40/0x80
> > > May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>] ?
> > igb_configure+0xaf/0x1d0 [igb]
> > > May 16 14:37:50 u1486 kernel: [<ffffffffa051bf62>] ?
> > igb_setup_rctl+0x22/0xb0 [igb]
> > > May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>]
> > igb_configure+0xaf/0x1d0 [igb]
> > > May 16 14:37:50 u1486 kernel: [<ffffffffa052408d>]
> > __igb_open+0xfd/0x300 [igb]
> > > May 16 14:37:50 u1486 kernel: [<ffffffff815ab260>] ?
> > call_netdevice_notifiers_info+0x40/0x70
> > > May 16 14:37:50 u1486 kernel: [<ffffffffa0524420>] igb_open+0x10/0x20
> > [igb]
> > > May 16 14:37:50 u1486 kernel: [<ffffffff815ac7f8>]
> > __dev_open+0xb8/0x110
> > > May 16 14:37:50 u1486 kernel: [<ffffffff815ac5fc>]
> > __dev_change_flags+0xac/0x180
> > > May 16 14:37:50 u1486 kernel: [<ffffffff815ac700>]
> > dev_change_flags+0x30/0x70
> > > May 16 14:37:50 u1486 kernel: [<ffffffff815c6685>] ?
> > lockdep_rtnl_is_held+0x15/0x20
> > > May 16 14:37:50 u1486 kernel: [<ffffffff816403a5>]
> > devinet_ioctl+0x5b5/0x620
> > > May 16 14:37:50 u1486 kernel: [<ffffffff81156660>] ?
> > trace_buffer_unlock_commit+0x60/0x80
> > > May 16 14:37:50 u1486 kernel: [<ffffffff81643033>] inet_ioctl+0x63/0x80
> > > May 16 14:37:50 u1486 kernel: [<ffffffff8158fd60>]
> > sock_do_ioctl+0x30/0x70
> > > May 16 14:37:50 u1486 kernel: [<ffffffff815901b3>]
> sock_ioctl+0x73/0x280
> > > May 16 14:37:50 u1486 kernel: [<ffffffff8121f678>] vfs_ioctl+0x18/0x30
> > > May 16 14:37:50 u1486 kernel: [<ffffffff81220057>]
> > do_vfs_ioctl+0x87/0x430
> > > May 16 14:37:50 u1486 kernel: [<ffffffff8100297e>] ?
> > syscall_trace_enter_phase2+0x6e/0x280
> > > May 16 14:37:50 u1486 kernel: [<ffffffff81220492>] SyS_ioctl+0x92/0xa0
> > > May 16 14:37:50 u1486 kernel: [<ffffffff81002fd3>]
> > do_syscall_64+0x63/0x130
> > > May 16 14:37:50 u1486 kernel: [<ffffffff8100201b>] ?
> > trace_hardirqs_on_thunk+0x1b/0x1d
> > > May 16 14:37:50 u1486 kernel: [<ffffffff816a981a>]
> > entry_SYSCALL64_slow_path+0x25/0x25
> > > ----------------------------------------------
> >
> > Since it's doing dump_stack in register_lock_class it appears some of
> > the error has been truncated before this stack trace. Can you confirm
> > that this is the complete output logged? By inspection, I would expect
> > to see one of the contextual messages from register_lock_class when it
> > calls dump_stack.
> 
> I will see if I still have a copy of, or can reproduce the trace along with more
> of the log messages leading up to it.

Yes, a tiny bit of more info before the trace.  I cleared the dmesg queue before running ifconfig and here is what I got, I also checked /var/log/messages and did not see any extra information there:
------------------------------------------------------------------------------------------------------------------------
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
dca service started, version 1.12.1
igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k
igb: Copyright (c) 2007-2014 Intel Corporation.
pps pps0: new PPS source ptp0
igb 0000:08:00.0: added PHC on eth1
igb 0000:08:00.0: Intel(R) Gigabit Ethernet Network Connection
igb 0000:08:00.0: eth1: (PCIe:2.5Gb/s:Width x1) a0:36:9f:0c:76:de
igb 0000:08:00.0: eth1: PBA No: FFFFFF-0FF
igb 0000:08:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)
igb 0000:09:00.0: added PHC on eth2
igb 0000:09:00.0: Intel(R) Gigabit Ethernet Network Connection
igb 0000:09:00.0: eth2: (PCIe:2.5Gb/s:Width x4) 00:1b:21:56:25:64
igb 0000:09:00.0: eth2: PBA No: Unknown
igb 0000:09:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
igb 0000:09:00.1: added PHC on eth3
igb 0000:09:00.1: Intel(R) Gigabit Ethernet Network Connection
igb 0000:09:00.1: eth3: (PCIe:2.5Gb/s:Width x4) 00:1b:21:56:25:65
igb 0000:09:00.1: eth3: PBA No: Unknown
igb 0000:09:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
BUG: spinlock bad magic on CPU#6, ifconfig/5569
 lock: 0xffff88007cbca080, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
CPU: 6 PID: 5569 Comm: ifconfig Not tainted 4.7.0-rc2_next_dev_rx_flow-00941-gb9e6e3f-dirty #2
Hardware name: Supermicro X7DBX/X7DBX, BIOS 2.1 06/23/2008
 0000000000000000 ffff880074393b08 ffffffff811e2937 0000000000000000
 ffffffff81717dbc ffff88007cbca080 0000000000000000 ffff880074393b28
 ffffffff81070724 ffff88007cbca080 ffff88007cbc8db0 ffff880074393b48
Call Trace:
 [<ffffffff811e2937>] dump_stack+0x53/0x74
 [<ffffffff81070724>] spin_dump+0x86/0x8b
 [<ffffffff8107074f>] spin_bug+0x26/0x28
 [<ffffffff810708d5>] do_raw_spin_lock+0x29/0x12c
 [<ffffffff811f55ad>] ? __do_once_done+0x71/0x78
 [<ffffffff814b488b>] _raw_spin_lock+0x1e/0x22
 [<ffffffffa00bd0d7>] igb_configure+0x2c8/0x3b1 [igb]
 [<ffffffffa00c0295>] __igb_open+0xb3/0x509 [igb]
 [<ffffffff81404799>] ? call_netdevice_notifiers_info+0x51/0x5a
 [<ffffffffa00c083c>] igb_open+0xb/0xd [igb]
 [<ffffffff81406542>] __dev_open+0xa7/0xf5
 [<ffffffff814063aa>] __dev_change_flags+0xb5/0x14d
 [<ffffffff81406465>] dev_change_flags+0x23/0x59
 [<ffffffff814b2b4f>] ? mutex_lock+0x27/0x38
[<ffffffff8145cc49>] devinet_ioctl+0x296/0x576
 [<ffffffff8145ecba>] inet_ioctl+0x92/0xaa
 [<ffffffff813f1566>] sock_ioctl+0x204/0x229
 [<ffffffff811092cf>] vfs_ioctl+0x13/0x23
 [<ffffffff811099e2>] do_vfs_ioctl+0x5e8/0x621
 [<ffffffff811fe00c>] ? __percpu_counter_add+0x8c/0xa8
 [<ffffffff810dfca7>] ? do_munmap+0x2e7/0x301
 [<ffffffff81109a5e>] SyS_ioctl+0x43/0x62
 [<ffffffff814b499b>] entry_SYSCALL_64_fastpath+0x13/0x8f
IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
igb 0000:08:00.0 eth1: igb: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
------------------------------------------------------------------------------------------------------------------------
> 
> >
> > Also, any chance of seeing a .config for this run or a freshly
> > reproduced run?

Sure, I've attached the current .config from the system that I just reproduced it on.  I know we should not use attachments on the lists, but a .config file is rather long for pasting into a message.  If it gets stripped let me know and I'll figure out how to get it to you.

> > By inspection at least there's no obvious locking or
> > otherwise issues in the open path (only *filter_restore() is executed on
> > open and it's a mostly a NOP if this is just patch 1 applied) so I think
> > we need some more detailed output since you have the only system that
> > seems
> > to produce this issue.
> 
> I can certainly get you a copy of the .config file on the affected systems,
> however, they will have changed some as the kernel gets updated frequently
> for tests, along with a make oldconfig pushing occasional changes in.
> Assuming I can re-apply the patch to the current tree I'll try and reproduce
> the issue and get you copies of a .config known to be current when the issue
> strikes.
> 
> >
> > Any other details you can provide would be appreciated. I'm happy to dig
> > into the root cause.
> 
> Only thing that immediately comes to mind is that my test systems all have
> multiple ports to minimize the lab space needed to get a sampling of the
> different parts.  I will see if I can reproduce the issue in a system with a single
> port.  If I remember correctly, it was a consistent issue, always appearing
> relatively quickly on the affected systems.
> 
> >
> > Thanks,
> > Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ifconfig-up-bug-dotconfig
Type: application/octet-stream
Size: 78378 bytes
Desc: ifconfig-up-bug-dotconfig
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160630/eccc7c8c/attachment-0001.obj>

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

['Matt Porter']

On Thu, Jun 30, 2016 at 01:20:44AM +0000, Brown, Aaron F wrote:
> > From: Brown, Aaron F
> > Sent: Wednesday, June 29, 2016 1:06 PM
> > To: Matt Porter <mporter@konsulko.com>
> > Cc: Gangfeng <gangfeng.huang@ni.com>; intel-wired-lan at lists.osuosl.org;
> > Ruhao Gao <ruhao.gao@ni.com>
> > Subject: RE: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> > network flow classification
> > 
> > > From: Matt Porter [mailto:mporter at konsulko.com]
> > > Sent: Wednesday, June 29, 2016 12:13 PM
> > > To: Brown, Aaron F <aaron.f.brown@intel.com>
> > > Cc: Gangfeng <gangfeng.huang@ni.com>; intel-wired-lan at lists.osuosl.org;
> > > Ruhao Gao <ruhao.gao@ni.com>
> > > Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of
> > RX
> > > network flow classification
> > >
> > > On Mon, May 16, 2016 at 10:09:04PM +0000, Brown, Aaron F wrote:
> > > > > From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org]
> > > On
> > > > > Behalf Of Gangfeng
> > > > > Sent: Monday, May 9, 2016 2:28 AM
> > > > > To: intel-wired-lan at lists.osuosl.org
> > > > > Cc: Gangfeng Huang <gangfeng.huang@ni.com>; Ruhao Gao
> > > > > <ruhao.gao@ni.com>
> > > > > Subject: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> > > > > network flow classification
> > > > >
> > > > > From: Gangfeng Huang <gangfeng.huang@ni.com>
> > > > >
> > > > > This patch is meant to allow for RX network flow classification to insert
> > > > > and remove Rx filter by ethtool. Ethtool interface has it's own rules
> > > > > manager
> > > > >
> > > > > Show all filters:
> > > > > $ ethtool -n eth0
> > > > > 4 RX rings available
> > > > > Total 2 rules
> > > > >
> > > > > Signed-off-by: Ruhao Gao <ruhao.gao@ni.com>
> > > > > Signed-off-by: Gangfeng Huang <gangfeng.huang@ni.com>
> > > > > ---
> > > > >  drivers/net/ethernet/intel/igb/igb.h         |  32 +++++
> > > > >  drivers/net/ethernet/intel/igb/igb_ethtool.c | 193
> > > > > +++++++++++++++++++++++++++
> > > > >  drivers/net/ethernet/intel/igb/igb_main.c    |  44 ++++++
> > > > >  3 files changed, 269 insertions(+)
> > > >
> > > > This patch is causing 3/4 of my regression systems to fail.  Driver load
> > > seems normal, but applying an IP address via ifconfig causes the following
> > > splat in dmesg and /var/log/messages:
> > >
> > > Hi Aaron,
> > >
> > > I'm looking at this series on current net-next and am wondering if you
> > > saw this issue with just patch 1 applied or you meant the entire series?
> > 
> > Hi Matt,
> > 
> > My recollection is that I saw it with just patch 1 applied.  And my procedure
> > when I see an issue with a series is to try and isolate it to the individual patch
> > and reply to the one in the series that triggers the issue, so I am pretty sure it
> > was with this patch applied and the rest of the series not applied.
> 
> I was able to apply this (v5 1/4) patch to a recent version of Jeff's next-queue / dev-branch (with a little fuzz) and reproduce the problem on one of the systems that was previously triggering it without any difficulty.  It does occur with just this one patch applied.  This was with the system that has an i211 and a pair of 82580 ports.  I will still try to sort out if it happens with just i211 or the pair of 82580s (leaning towards the i211 as a system with a pair of 82580s and an i210 worked fine) but have been searching for another i211 as the system in question is at the bottom of a rack with a bunch of systems stacked on top of it, making the card cage rather difficult to get to.

Ok, thanks for trying this again. I'm switching to that branch and
trying to get a multi-port system together to try to reproduce here
though it sounds like I may need to pick up more than the i210's I have
handy.

-Matt

> > > I've been working with this on an i210 and haven't reproduced your
> > > results yet either with just the (non-functional) first patch applied or
> > > the entire series. However, I noticed you had no problems on your system
> > > with an i210.
> > 
> > Correct, the system with an i210 included was one of the ones not affected
> > by this.  I'm not sure if that is due to it not being a problem with the i210 or
> > something more elusive like the system's chipset of a variation in the .config.
> > 
> > >
> > > > ----------------------------------------------
> > > > May 16 14:37:50 u1486 kernel: Hardware name: Supermicro A1SAi/A1SRi,
> > > BIOS 1.0b 11/06/2013
> > > > May 16 14:37:50 u1486 kernel: 0000000000000000 ffff880849ad3938
> > > ffffffff813373d7 0000000000000007
> > > > May 16 14:37:50 u1486 kernel: 0000000000000006 0000000000000000
> > > ffff88085c2f6770 ffff880849ad3a58
> > > > May 16 14:37:50 u1486 kernel: ffffffff810c4e13 ffff880849ad39f8
> > > 0000000000000005 0000000000000000
> > > > May 16 14:37:50 u1486 kernel: Call Trace:
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff813373d7>]
> > dump_stack+0x6b/0xa4
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff810c4e13>]
> > > register_lock_class+0x523/0x5c0
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff8136644b>] ?
> > > check_preemption_disabled+0x1b/0x110
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff811f5655>] ? kfree+0x1a5/0x3a0
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff81366553>] ?
> > > __this_cpu_preempt_check+0x13/0x20
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff810c7ae0>]
> > > __lock_acquire+0x80/0x5d0
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff811f83f5>] ?
> > > __kmalloc+0x265/0x3a0
> > > > May 16 14:37:50 u1486 kernel: [<ffffffffa051864f>] ? kzalloc+0xf/0x20
> > [igb]
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff810c80fa>]
> > > lock_acquire+0xca/0x240
> > > > May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>] ?
> > > igb_configure+0xaf/0x1d0 [igb]
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff815b958b>] ?
> > > netdev_rss_key_fill+0x5b/0xa0
> > > > May 16 14:37:50 u1486 kernel: [<ffffffffa052dfb9>] ?
> > > igb_vfta_set+0x189/0x1f0 [igb]
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff816a8930>]
> > > _raw_spin_lock+0x40/0x80
> > > > May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>] ?
> > > igb_configure+0xaf/0x1d0 [igb]
> > > > May 16 14:37:50 u1486 kernel: [<ffffffffa051bf62>] ?
> > > igb_setup_rctl+0x22/0xb0 [igb]
> > > > May 16 14:37:50 u1486 kernel: [<ffffffffa0520c3f>]
> > > igb_configure+0xaf/0x1d0 [igb]
> > > > May 16 14:37:50 u1486 kernel: [<ffffffffa052408d>]
> > > __igb_open+0xfd/0x300 [igb]
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff815ab260>] ?
> > > call_netdevice_notifiers_info+0x40/0x70
> > > > May 16 14:37:50 u1486 kernel: [<ffffffffa0524420>] igb_open+0x10/0x20
> > > [igb]
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff815ac7f8>]
> > > __dev_open+0xb8/0x110
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff815ac5fc>]
> > > __dev_change_flags+0xac/0x180
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff815ac700>]
> > > dev_change_flags+0x30/0x70
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff815c6685>] ?
> > > lockdep_rtnl_is_held+0x15/0x20
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff816403a5>]
> > > devinet_ioctl+0x5b5/0x620
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff81156660>] ?
> > > trace_buffer_unlock_commit+0x60/0x80
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff81643033>] inet_ioctl+0x63/0x80
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff8158fd60>]
> > > sock_do_ioctl+0x30/0x70
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff815901b3>]
> > sock_ioctl+0x73/0x280
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff8121f678>] vfs_ioctl+0x18/0x30
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff81220057>]
> > > do_vfs_ioctl+0x87/0x430
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff8100297e>] ?
> > > syscall_trace_enter_phase2+0x6e/0x280
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff81220492>] SyS_ioctl+0x92/0xa0
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff81002fd3>]
> > > do_syscall_64+0x63/0x130
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff8100201b>] ?
> > > trace_hardirqs_on_thunk+0x1b/0x1d
> > > > May 16 14:37:50 u1486 kernel: [<ffffffff816a981a>]
> > > entry_SYSCALL64_slow_path+0x25/0x25
> > > > ----------------------------------------------
> > >
> > > Since it's doing dump_stack in register_lock_class it appears some of
> > > the error has been truncated before this stack trace. Can you confirm
> > > that this is the complete output logged? By inspection, I would expect
> > > to see one of the contextual messages from register_lock_class when it
> > > calls dump_stack.
> > 
> > I will see if I still have a copy of, or can reproduce the trace along with more
> > of the log messages leading up to it.
> 
> Yes, a tiny bit of more info before the trace.  I cleared the dmesg queue before running ifconfig and here is what I got, I also checked /var/log/messages and did not see any extra information there:
> ------------------------------------------------------------------------------------------------------------------------

Aha, yes, that helps isolate it a bit further.

> pps_core: LinuxPPS API ver. 1 registered
> pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
> PTP clock support registered
> dca service started, version 1.12.1
> igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k
> igb: Copyright (c) 2007-2014 Intel Corporation.
> pps pps0: new PPS source ptp0
> igb 0000:08:00.0: added PHC on eth1
> igb 0000:08:00.0: Intel(R) Gigabit Ethernet Network Connection
> igb 0000:08:00.0: eth1: (PCIe:2.5Gb/s:Width x1) a0:36:9f:0c:76:de
> igb 0000:08:00.0: eth1: PBA No: FFFFFF-0FF
> igb 0000:08:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)
> igb 0000:09:00.0: added PHC on eth2
> igb 0000:09:00.0: Intel(R) Gigabit Ethernet Network Connection
> igb 0000:09:00.0: eth2: (PCIe:2.5Gb/s:Width x4) 00:1b:21:56:25:64
> igb 0000:09:00.0: eth2: PBA No: Unknown
> igb 0000:09:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
> igb 0000:09:00.1: added PHC on eth3
> igb 0000:09:00.1: Intel(R) Gigabit Ethernet Network Connection
> igb 0000:09:00.1: eth3: (PCIe:2.5Gb/s:Width x4) 00:1b:21:56:25:65
> igb 0000:09:00.1: eth3: PBA No: Unknown
> igb 0000:09:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
> BUG: spinlock bad magic on CPU#6, ifconfig/5569
>  lock: 0xffff88007cbca080, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
> CPU: 6 PID: 5569 Comm: ifconfig Not tainted 4.7.0-rc2_next_dev_rx_flow-00941-gb9e6e3f-dirty #2
> Hardware name: Supermicro X7DBX/X7DBX, BIOS 2.1 06/23/2008
>  0000000000000000 ffff880074393b08 ffffffff811e2937 0000000000000000
>  ffffffff81717dbc ffff88007cbca080 0000000000000000 ffff880074393b28
>  ffffffff81070724 ffff88007cbca080 ffff88007cbc8db0 ffff880074393b48
> Call Trace:
>  [<ffffffff811e2937>] dump_stack+0x53/0x74
>  [<ffffffff81070724>] spin_dump+0x86/0x8b
>  [<ffffffff8107074f>] spin_bug+0x26/0x28
>  [<ffffffff810708d5>] do_raw_spin_lock+0x29/0x12c
>  [<ffffffff811f55ad>] ? __do_once_done+0x71/0x78
>  [<ffffffff814b488b>] _raw_spin_lock+0x1e/0x22
>  [<ffffffffa00bd0d7>] igb_configure+0x2c8/0x3b1 [igb]
>  [<ffffffffa00c0295>] __igb_open+0xb3/0x509 [igb]
>  [<ffffffff81404799>] ? call_netdevice_notifiers_info+0x51/0x5a
>  [<ffffffffa00c083c>] igb_open+0xb/0xd [igb]
>  [<ffffffff81406542>] __dev_open+0xa7/0xf5
>  [<ffffffff814063aa>] __dev_change_flags+0xb5/0x14d
>  [<ffffffff81406465>] dev_change_flags+0x23/0x59
>  [<ffffffff814b2b4f>] ? mutex_lock+0x27/0x38
> [<ffffffff8145cc49>] devinet_ioctl+0x296/0x576
>  [<ffffffff8145ecba>] inet_ioctl+0x92/0xaa
>  [<ffffffff813f1566>] sock_ioctl+0x204/0x229
>  [<ffffffff811092cf>] vfs_ioctl+0x13/0x23
>  [<ffffffff811099e2>] do_vfs_ioctl+0x5e8/0x621
>  [<ffffffff811fe00c>] ? __percpu_counter_add+0x8c/0xa8
>  [<ffffffff810dfca7>] ? do_munmap+0x2e7/0x301
>  [<ffffffff81109a5e>] SyS_ioctl+0x43/0x62
>  [<ffffffff814b499b>] entry_SYSCALL_64_fastpath+0x13/0x8f
> IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
> igb 0000:08:00.0 eth1: igb: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
> IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> ------------------------------------------------------------------------------------------------------------------------
> > 
> > >
> > > Also, any chance of seeing a .config for this run or a freshly
> > > reproduced run?
> 
> Sure, I've attached the current .config from the system that I just reproduced it on.  I know we should not use attachments on the lists, but a .config file is rather long for pasting into a message.  If it gets stripped let me know and I'll figure out how to get it to you.

Got it. Thanks for everything so far, this gives me quite a bit more to
go on for debugging.

-Matt

> 
> > > By inspection at least there's no obvious locking or
> > > otherwise issues in the open path (only *filter_restore() is executed on
> > > open and it's a mostly a NOP if this is just patch 1 applied) so I think
> > > we need some more detailed output since you have the only system that
> > > seems
> > > to produce this issue.
> > 
> > I can certainly get you a copy of the .config file on the affected systems,
> > however, they will have changed some as the kernel gets updated frequently
> > for tests, along with a make oldconfig pushing occasional changes in.
> > Assuming I can re-apply the patch to the current tree I'll try and reproduce
> > the issue and get you copies of a .config known to be current when the issue
> > strikes.
> > 
> > >
> > > Any other details you can provide would be appreciated. I'm happy to dig
> > > into the root cause.
> > 
> > Only thing that immediately comes to mind is that my test systems all have
> > multiple ports to minimize the lab space needed to get a sampling of the
> > different parts.  I will see if I can reproduce the issue in a system with a single
> > port.  If I remember correctly, it was a consistent issue, always appearing
> > relatively quickly on the affected systems.
> > 
> > >
> > > Thanks,
> > > Matt

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

['Matt Porter']

On Thu, Jun 30, 2016 at 01:20:44AM +0000, Brown, Aaron F wrote:
> > From: Brown, Aaron F
> > Sent: Wednesday, June 29, 2016 1:06 PM
> > To: Matt Porter <mporter@konsulko.com>
> > Cc: Gangfeng <gangfeng.huang@ni.com>; intel-wired-lan at lists.osuosl.org;
> > Ruhao Gao <ruhao.gao@ni.com>
> > Subject: RE: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> > network flow classification
> > 
> > > From: Matt Porter [mailto:mporter at konsulko.com]
> > > Sent: Wednesday, June 29, 2016 12:13 PM
> > > To: Brown, Aaron F <aaron.f.brown@intel.com>
> > > Cc: Gangfeng <gangfeng.huang@ni.com>; intel-wired-lan at lists.osuosl.org;
> > > Ruhao Gao <ruhao.gao@ni.com>
> > > Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of
> > RX
> > > network flow classification
> > >
> > > On Mon, May 16, 2016 at 10:09:04PM +0000, Brown, Aaron F wrote:
> > > > > From: Intel-wired-lan [mailto:intel-wired-lan-bounces at lists.osuosl.org]
> > > On
> > > > > Behalf Of Gangfeng
> > > > > Sent: Monday, May 9, 2016 2:28 AM
> > > > > To: intel-wired-lan at lists.osuosl.org
> > > > > Cc: Gangfeng Huang <gangfeng.huang@ni.com>; Ruhao Gao
> > > > > <ruhao.gao@ni.com>
> > > > > Subject: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> > > > > network flow classification
> > > > >
> > > > > From: Gangfeng Huang <gangfeng.huang@ni.com>
> > > > >
> > > > > This patch is meant to allow for RX network flow classification to insert
> > > > > and remove Rx filter by ethtool. Ethtool interface has it's own rules
> > > > > manager
> > > > >
> > > > > Show all filters:
> > > > > $ ethtool -n eth0
> > > > > 4 RX rings available
> > > > > Total 2 rules
> > > > >
> > > > > Signed-off-by: Ruhao Gao <ruhao.gao@ni.com>
> > > > > Signed-off-by: Gangfeng Huang <gangfeng.huang@ni.com>
> > > > > ---
> > > > >  drivers/net/ethernet/intel/igb/igb.h         |  32 +++++
> > > > >  drivers/net/ethernet/intel/igb/igb_ethtool.c | 193
> > > > > +++++++++++++++++++++++++++
> > > > >  drivers/net/ethernet/intel/igb/igb_main.c    |  44 ++++++
> > > > >  3 files changed, 269 insertions(+)
> > > >
> > > > This patch is causing 3/4 of my regression systems to fail.  Driver load
> > > seems normal, but applying an IP address via ifconfig causes the following
> > > splat in dmesg and /var/log/messages:
> > >
> > > Hi Aaron,
> > >
> > > I'm looking at this series on current net-next and am wondering if you
> > > saw this issue with just patch 1 applied or you meant the entire series?
> > 
> > Hi Matt,
> > 
> > My recollection is that I saw it with just patch 1 applied.  And my procedure
> > when I see an issue with a series is to try and isolate it to the individual patch
> > and reply to the one in the series that triggers the issue, so I am pretty sure it
> > was with this patch applied and the rest of the series not applied.
> 
> I was able to apply this (v5 1/4) patch to a recent version of Jeff's next-queue / dev-branch (with a little fuzz) and reproduce the problem on one of the systems that was previously triggering it without any difficulty.  It does occur with just this one patch applied.  This was with the system that has an i211 and a pair of 82580 ports.  I will still try to sort out if it happens with just i211 or the pair of 82580s (leaning towards the i211 as a system with a pair of 82580s and an i210 worked fine) but have been searching for another i211 as the system in question is at the bottom of a rack with a bunch of systems stacked on top of it, making the card cage rather difficult to get to.

Ok, the full oops output made me notice the problem. Can you try the
following untested fix on your failing system? It'll apply against
patch 1/4 and is build tested against the next-queue dev-queue branch.

-Matt

From 8773d0f09741d7a318cdd96cf5aad2ddb79096e7 Mon Sep 17 00:00:00 2001
From: Matt Porter <mporter@konsulko.com>
Date: Thu, 30 Jun 2016 11:47:50 -0400
Subject: [PATCH] igb: Fix missing lock init in rx network flow classification
 support

"[net-next,v5,1/4] igb: add support of RX network flow classification"
adds a new nfc_lock to each adapter to protect the rx filter hash list.
This lock is not initialized before use which results in intermittent
oopses. Initialize this lock during probe to fix the issue.

Signed-off-by: Matt Porter <mporter@konsulko.com>
---
 drivers/net/ethernet/intel/igb/igb_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index c04b1c2..e5a4949 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -3075,6 +3075,7 @@ static int igb_sw_init(struct igb_adapter *adapter)
 				  VLAN_HLEN;
 	adapter->min_frame_size = ETH_ZLEN + ETH_FCS_LEN;
 
+	spin_lock_init(&adapter->nfc_lock);
 	spin_lock_init(&adapter->stats64_lock);
 #ifdef CONFIG_PCI_IOV
 	switch (hw->mac.type) {
-- 
2.7.0

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

[Brown, Aaron F]

> -----Original Message-----
> From: 'Matt Porter' [mailto:mporter at konsulko.com]
> Sent: Thursday, June 30, 2016 9:16 AM
> To: Brown, Aaron F <aaron.f.brown@intel.com>
> Cc: 'Gangfeng' <gangfeng.huang@ni.com>; 'intel-wired-lan at lists.osuosl.org'
> <intel-wired-lan@lists.osuosl.org>; 'Ruhao Gao' <ruhao.gao@ni.com>
> Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> network flow classification
>
<snip>
> 
> Ok, the full oops output made me notice the problem. Can you try the
> following untested fix on your failing system? It'll apply against
> patch 1/4 and is build tested against the next-queue dev-queue branch.
> 
> -Matt
> 
> From 8773d0f09741d7a318cdd96cf5aad2ddb79096e7 Mon Sep 17 00:00:00
> 2001
> From: Matt Porter <mporter@konsulko.com>
> Date: Thu, 30 Jun 2016 11:47:50 -0400
> Subject: [PATCH] igb: Fix missing lock init in rx network flow classification
>  support
> 
> "[net-next,v5,1/4] igb: add support of RX network flow classification"
> adds a new nfc_lock to each adapter to protect the rx filter hash list.
> This lock is not initialized before use which results in intermittent
> oopses. Initialize this lock during probe to fix the issue.
> 
> Signed-off-by: Matt Porter <mporter@konsulko.com>
> ---
>  drivers/net/ethernet/intel/igb/igb_main.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> b/drivers/net/ethernet/intel/igb/igb_main.c
> index c04b1c2..e5a4949 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -3075,6 +3075,7 @@ static int igb_sw_init(struct igb_adapter *adapter)
>  				  VLAN_HLEN;
>  	adapter->min_frame_size = ETH_ZLEN + ETH_FCS_LEN;
> 
> +	spin_lock_init(&adapter->nfc_lock);
>  	spin_lock_init(&adapter->stats64_lock);
>  #ifdef CONFIG_PCI_IOV
>  	switch (hw->mac.type) {
> --
> 2.7.0

Bingo!  That resolved it.  I can now load and bind (with ifconfig) on all the systems that were previously giving me the splat without seeing anything out of the ordinary.

Thanks,
Aaron

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

['Matt Porter']

On Thu, Jun 30, 2016 at 07:51:01PM +0000, Brown, Aaron F wrote:
> 
> 
> > -----Original Message-----
> > From: 'Matt Porter' [mailto:mporter at konsulko.com]
> > Sent: Thursday, June 30, 2016 9:16 AM
> > To: Brown, Aaron F <aaron.f.brown@intel.com>
> > Cc: 'Gangfeng' <gangfeng.huang@ni.com>; 'intel-wired-lan at lists.osuosl.org'
> > <intel-wired-lan@lists.osuosl.org>; 'Ruhao Gao' <ruhao.gao@ni.com>
> > Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX
> > network flow classification
> >
> <snip>
> > 
> > Ok, the full oops output made me notice the problem. Can you try the
> > following untested fix on your failing system? It'll apply against
> > patch 1/4 and is build tested against the next-queue dev-queue branch.
> > 
> > -Matt
> > 
> > From 8773d0f09741d7a318cdd96cf5aad2ddb79096e7 Mon Sep 17 00:00:00
> > 2001
> > From: Matt Porter <mporter@konsulko.com>
> > Date: Thu, 30 Jun 2016 11:47:50 -0400
> > Subject: [PATCH] igb: Fix missing lock init in rx network flow classification
> >  support
> > 
> > "[net-next,v5,1/4] igb: add support of RX network flow classification"
> > adds a new nfc_lock to each adapter to protect the rx filter hash list.
> > This lock is not initialized before use which results in intermittent
> > oopses. Initialize this lock during probe to fix the issue.
> > 
> > Signed-off-by: Matt Porter <mporter@konsulko.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> > b/drivers/net/ethernet/intel/igb/igb_main.c
> > index c04b1c2..e5a4949 100644
> > --- a/drivers/net/ethernet/intel/igb/igb_main.c
> > +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> > @@ -3075,6 +3075,7 @@ static int igb_sw_init(struct igb_adapter *adapter)
> >  				  VLAN_HLEN;
> >  	adapter->min_frame_size = ETH_ZLEN + ETH_FCS_LEN;
> > 
> > +	spin_lock_init(&adapter->nfc_lock);
> >  	spin_lock_init(&adapter->stats64_lock);
> >  #ifdef CONFIG_PCI_IOV
> >  	switch (hw->mac.type) {
> > --
> > 2.7.0
> 
> Bingo!  That resolved it.  I can now load and bind (with ifconfig) on all the systems that were previously giving me the splat without seeing anything out of the ordinary.

Excellent! Thanks for doing the grunt testing work on it. ;) Looks like
this was the only remaining issue from the v5 submission.

Gangfeng: can you fold this fix into a v6 submission? If this isn't
something you are still working on then let me know and I can resubmit.

Regards,
Matt

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

[Gangfeng Huang]

Hi Matt,

Thank you very much for the fix and I will be very appreciate if you can help to resubmit it.  Because I caught pneumonia and do not have time to submit it in this week. 

If you are too busy, I can submit the v6 in next week.

Gangfeng Huang

-----Original Message-----
From: 'Matt Porter' [mailto:mporter at konsulko.com] 
Sent: 2016?7?1? 4:11
To: Brown, Aaron F <aaron.f.brown@intel.com>
Cc: Gangfeng Huang <gangfeng.huang@ni.com>; 'intel-wired-lan at lists.osuosl.org' <intel-wired-lan@lists.osuosl.org>; Ruhao Gao <ruhao.gao@ni.com>
Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

On Thu, Jun 30, 2016 at 07:51:01PM +0000, Brown, Aaron F wrote:
> 
> 
> > -----Original Message-----
> > From: 'Matt Porter' [mailto:mporter at konsulko.com]
> > Sent: Thursday, June 30, 2016 9:16 AM
> > To: Brown, Aaron F <aaron.f.brown@intel.com>
> > Cc: 'Gangfeng' <gangfeng.huang@ni.com>; 'intel-wired-lan at lists.osuosl.org'
> > <intel-wired-lan@lists.osuosl.org>; 'Ruhao Gao' <ruhao.gao@ni.com>
> > Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add 
> > support of RX network flow classification
> >
> <snip>
> > 
> > Ok, the full oops output made me notice the problem. Can you try the 
> > following untested fix on your failing system? It'll apply against 
> > patch 1/4 and is build tested against the next-queue dev-queue branch.
> > 
> > -Matt
> > 
> > From 8773d0f09741d7a318cdd96cf5aad2ddb79096e7 Mon Sep 17 00:00:00
> > 2001
> > From: Matt Porter <mporter@konsulko.com>
> > Date: Thu, 30 Jun 2016 11:47:50 -0400
> > Subject: [PATCH] igb: Fix missing lock init in rx network flow 
> > classification  support
> > 
> > "[net-next,v5,1/4] igb: add support of RX network flow classification"
> > adds a new nfc_lock to each adapter to protect the rx filter hash list.
> > This lock is not initialized before use which results in 
> > intermittent oopses. Initialize this lock during probe to fix the issue.
> > 
> > Signed-off-by: Matt Porter <mporter@konsulko.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> > b/drivers/net/ethernet/intel/igb/igb_main.c
> > index c04b1c2..e5a4949 100644
> > --- a/drivers/net/ethernet/intel/igb/igb_main.c
> > +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> > @@ -3075,6 +3075,7 @@ static int igb_sw_init(struct igb_adapter *adapter)
> >  				  VLAN_HLEN;
> >  	adapter->min_frame_size = ETH_ZLEN + ETH_FCS_LEN;
> > 
> > +	spin_lock_init(&adapter->nfc_lock);
> >  	spin_lock_init(&adapter->stats64_lock);
> >  #ifdef CONFIG_PCI_IOV
> >  	switch (hw->mac.type) {
> > --
> > 2.7.0
> 
> Bingo!  That resolved it.  I can now load and bind (with ifconfig) on all the systems that were previously giving me the splat without seeing anything out of the ordinary.

Excellent! Thanks for doing the grunt testing work on it. ;) Looks like this was the only remaining issue from the v5 submission.

Gangfeng: can you fold this fix into a v6 submission? If this isn't something you are still working on then let me know and I can resubmit.

Regards,
Matt

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

[Gangfeng Huang]

Hi matt,

I have add your fix to the v6 patches and resubmit them, please help to test it.

Thanks 
Gangfeng Huang

-----Original Message-----
From: 'Matt Porter' [mailto:mporter at konsulko.com] 
Sent: 2016?7?1? 4:11
To: Brown, Aaron F <aaron.f.brown@intel.com>
Cc: Gangfeng Huang <gangfeng.huang@ni.com>; 'intel-wired-lan at lists.osuosl.org' <intel-wired-lan@lists.osuosl.org>; Ruhao Gao <ruhao.gao@ni.com>
Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

On Thu, Jun 30, 2016 at 07:51:01PM +0000, Brown, Aaron F wrote:
> 
> 
> > -----Original Message-----
> > From: 'Matt Porter' [mailto:mporter at konsulko.com]
> > Sent: Thursday, June 30, 2016 9:16 AM
> > To: Brown, Aaron F <aaron.f.brown@intel.com>
> > Cc: 'Gangfeng' <gangfeng.huang@ni.com>; 'intel-wired-lan at lists.osuosl.org'
> > <intel-wired-lan@lists.osuosl.org>; 'Ruhao Gao' <ruhao.gao@ni.com>
> > Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add 
> > support of RX network flow classification
> >
> <snip>
> > 
> > Ok, the full oops output made me notice the problem. Can you try the 
> > following untested fix on your failing system? It'll apply against 
> > patch 1/4 and is build tested against the next-queue dev-queue branch.
> > 
> > -Matt
> > 
> > From 8773d0f09741d7a318cdd96cf5aad2ddb79096e7 Mon Sep 17 00:00:00
> > 2001
> > From: Matt Porter <mporter@konsulko.com>
> > Date: Thu, 30 Jun 2016 11:47:50 -0400
> > Subject: [PATCH] igb: Fix missing lock init in rx network flow 
> > classification  support
> > 
> > "[net-next,v5,1/4] igb: add support of RX network flow classification"
> > adds a new nfc_lock to each adapter to protect the rx filter hash list.
> > This lock is not initialized before use which results in 
> > intermittent oopses. Initialize this lock during probe to fix the issue.
> > 
> > Signed-off-by: Matt Porter <mporter@konsulko.com>
> > ---
> >  drivers/net/ethernet/intel/igb/igb_main.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> > b/drivers/net/ethernet/intel/igb/igb_main.c
> > index c04b1c2..e5a4949 100644
> > --- a/drivers/net/ethernet/intel/igb/igb_main.c
> > +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> > @@ -3075,6 +3075,7 @@ static int igb_sw_init(struct igb_adapter *adapter)
> >  				  VLAN_HLEN;
> >  	adapter->min_frame_size = ETH_ZLEN + ETH_FCS_LEN;
> > 
> > +	spin_lock_init(&adapter->nfc_lock);
> >  	spin_lock_init(&adapter->stats64_lock);
> >  #ifdef CONFIG_PCI_IOV
> >  	switch (hw->mac.type) {
> > --
> > 2.7.0
> 
> Bingo!  That resolved it.  I can now load and bind (with ifconfig) on all the systems that were previously giving me the splat without seeing anything out of the ordinary.

Excellent! Thanks for doing the grunt testing work on it. ;) Looks like this was the only remaining issue from the v5 submission.

Gangfeng: can you fold this fix into a v6 submission? If this isn't something you are still working on then let me know and I can resubmit.

Regards,
Matt

[Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification

['Matt Porter']

On Wed, Jul 06, 2016 at 08:28:46AM +0000, Gangfeng Huang wrote:
> Hi matt,
> 
> I have add your fix to the v6 patches and resubmit them, please help to test it.

Ok, thanks. I'll retest with v6 and reply back to that thread. I hope
you are feeling better.

-Matt

> -----Original Message-----
> From: 'Matt Porter' [mailto:mporter at konsulko.com] 
> Sent: 2016?7?1? 4:11
> To: Brown, Aaron F <aaron.f.brown@intel.com>
> Cc: Gangfeng Huang <gangfeng.huang@ni.com>; 'intel-wired-lan at lists.osuosl.org' <intel-wired-lan@lists.osuosl.org>; Ruhao Gao <ruhao.gao@ni.com>
> Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add support of RX network flow classification
> 
> On Thu, Jun 30, 2016 at 07:51:01PM +0000, Brown, Aaron F wrote:
> > 
> > 
> > > -----Original Message-----
> > > From: 'Matt Porter' [mailto:mporter at konsulko.com]
> > > Sent: Thursday, June 30, 2016 9:16 AM
> > > To: Brown, Aaron F <aaron.f.brown@intel.com>
> > > Cc: 'Gangfeng' <gangfeng.huang@ni.com>; 'intel-wired-lan at lists.osuosl.org'
> > > <intel-wired-lan@lists.osuosl.org>; 'Ruhao Gao' <ruhao.gao@ni.com>
> > > Subject: Re: [Intel-wired-lan] [PATCH net-next v5 1/4] igb: add 
> > > support of RX network flow classification
> > >
> > <snip>
> > > 
> > > Ok, the full oops output made me notice the problem. Can you try the 
> > > following untested fix on your failing system? It'll apply against 
> > > patch 1/4 and is build tested against the next-queue dev-queue branch.
> > > 
> > > -Matt
> > > 
> > > From 8773d0f09741d7a318cdd96cf5aad2ddb79096e7 Mon Sep 17 00:00:00
> > > 2001
> > > From: Matt Porter <mporter@konsulko.com>
> > > Date: Thu, 30 Jun 2016 11:47:50 -0400
> > > Subject: [PATCH] igb: Fix missing lock init in rx network flow 
> > > classification  support
> > > 
> > > "[net-next,v5,1/4] igb: add support of RX network flow classification"
> > > adds a new nfc_lock to each adapter to protect the rx filter hash list.
> > > This lock is not initialized before use which results in 
> > > intermittent oopses. Initialize this lock during probe to fix the issue.
> > > 
> > > Signed-off-by: Matt Porter <mporter@konsulko.com>
> > > ---
> > >  drivers/net/ethernet/intel/igb/igb_main.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> > > b/drivers/net/ethernet/intel/igb/igb_main.c
> > > index c04b1c2..e5a4949 100644
> > > --- a/drivers/net/ethernet/intel/igb/igb_main.c
> > > +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> > > @@ -3075,6 +3075,7 @@ static int igb_sw_init(struct igb_adapter *adapter)
> > >  				  VLAN_HLEN;
> > >  	adapter->min_frame_size = ETH_ZLEN + ETH_FCS_LEN;
> > > 
> > > +	spin_lock_init(&adapter->nfc_lock);
> > >  	spin_lock_init(&adapter->stats64_lock);
> > >  #ifdef CONFIG_PCI_IOV
> > >  	switch (hw->mac.type) {
> > > --
> > > 2.7.0
> > 
> > Bingo!  That resolved it.  I can now load and bind (with ifconfig) on all the systems that were previously giving me the splat without seeing anything out of the ordinary.
> 
> Excellent! Thanks for doing the grunt testing work on it. ;) Looks like this was the only remaining issue from the v5 submission.
> 
> Gangfeng: can you fold this fix into a v6 submission? If this isn't something you are still working on then let me know and I can resubmit.
> 
> Regards,
> Matt
> _______________________________________________
> Intel-wired-lan mailing list
> Intel-wired-lan at lists.osuosl.org
> http://lists.osuosl.org/mailman/listinfo/intel-wired-lan

[Intel-wired-lan] [PATCH net-next v5 2/4] igb: support RX flow classification by ethertype

[Gangfeng]

From: Gangfeng Huang <gangfeng.huang@ni.com>

This patch is meant to allow for RX network flow classification to insert
and remove ethertype filter by ethtool

Example:
Add an ethertype filter:
$ ethtool -N eth0 flow-type ether proto 0x88F8 action 2

Show all filters:
$ ethtool -n eth0
4 RX rings available
Total 1 rules

Filter: 15
	Flow Type: Raw Ethernet
	Src MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF
	Dest MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF
	Ethertype: 0x88F8 mask: 0x0
	Action: Direct to queue 2

Delete the filter by location:
$ ethtool -N delete 15

Signed-off-by: Ruhao Gao <ruhao.gao@ni.com>
Signed-off-by: Gangfeng Huang <gangfeng.huang@ni.com>
---
 drivers/net/ethernet/intel/igb/e1000_82575.h |  5 ++
 drivers/net/ethernet/intel/igb/igb.h         | 20 +++++++-
 drivers/net/ethernet/intel/igb/igb_ethtool.c | 77 +++++++++++++++++++++++++++-
 drivers/net/ethernet/intel/igb/igb_ptp.c     |  4 +-
 4 files changed, 102 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.h b/drivers/net/ethernet/intel/igb/e1000_82575.h
index 199ff98..acf0605 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.h
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.h
@@ -188,6 +188,11 @@ struct e1000_adv_tx_context_desc {
 /* ETQF register bit definitions */
 #define E1000_ETQF_FILTER_ENABLE   BIT(26)
 #define E1000_ETQF_1588            BIT(30)
+#define E1000_ETQF_IMM_INT         BIT(29)
+#define E1000_ETQF_QUEUE_ENABLE    BIT(31)
+#define E1000_ETQF_QUEUE_SHIFT     16
+#define E1000_ETQF_QUEUE_MASK      0x00070000
+#define E1000_ETQF_ETYPE_MASK      0x0000FFFF
 
 /* FTQF register bit definitions */
 #define E1000_FTQF_VF_BP               0x00008000
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index cdc214c..9bdc8a8 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -350,13 +350,27 @@ struct hwmon_buff {
 	};
 #endif
 
+/* The number of L2 ether-type filter registers, Index 3 is reserved
+ * for PTP 1588 timestamp
+ */
+#define MAX_ETYPE_FILTER  (4 - 1)
+
+/* ETQF filter list: one static filter per filter consumer. This is
+ *                   to avoid filter collisions later. Add new filters
+ *                   here!!
+ *
+ * Current filters:
+ *    1588 (0x88f7):         Filter 3
+ */
+#define IGB_ETQF_FILTER_1588   3
+
 #define IGB_N_EXTTS	2
 #define IGB_N_PEROUT	2
 #define IGB_N_SDP	4
 #define IGB_RETA_SIZE	128
 
 enum igb_filter_match_flags {
-	IGB_FILTER_FLAG_NONE        = 0x0,
+	IGB_FILTER_FLAG_ETHER_TYPE  = 0x1,
 };
 
 #define IGB_MAX_RXNFC_FILTERS 16
@@ -365,13 +379,16 @@ enum igb_filter_match_flags {
 struct igb_nfc_input {
 	/* Byte layout in order, all values with MSB first:
 	* match_flags - 1 byte
+	* etype       - 2 bytes
 	*/
 	u8     match_flags;
+	__be16 etype;
 };
 
 struct igb_nfc_filter {
 	struct hlist_node nfc_node;
 	struct igb_nfc_input filter;
+	u16 etype_reg_index;
 	u16 sw_idx;
 	u16 action;
 };
@@ -499,6 +516,7 @@ struct igb_adapter {
 	unsigned int nfc_filter_count;
 	/* lock for RX network flow classification filter */
 	spinlock_t nfc_lock;
+	bool etype_bitmap[MAX_ETYPE_FILTER];
 };
 
 #define IGB_FLAG_HAS_MSI		BIT(0)
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 2599826..00e3387 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -2431,6 +2431,7 @@ static int igb_get_ts_info(struct net_device *dev,
 	}
 }
 
+#define ETHER_TYPE_FULL_MASK ((__force __be16)~0)
 static int igb_get_ethtool_nfc_entry(struct igb_adapter *adapter,
 				     struct ethtool_rxnfc *cmd)
 {
@@ -2448,6 +2449,13 @@ static int igb_get_ethtool_nfc_entry(struct igb_adapter *adapter,
 	if (!rule || fsp->location != rule->sw_idx)
 		return -EINVAL;
 
+	if (rule->filter.match_flags & IGB_FILTER_FLAG_ETHER_TYPE) {
+		fsp->flow_type = ETHER_FLOW;
+		fsp->ring_cookie = rule->action;
+		fsp->h_u.ether_spec.h_proto = rule->filter.etype;
+		fsp->m_u.ether_spec.h_proto = ETHER_TYPE_FULL_MASK;
+		return 0;
+	}
 	return -EINVAL;
 }
 
@@ -2650,13 +2658,75 @@ static int igb_set_rss_hash_opt(struct igb_adapter *adapter,
 	return 0;
 }
 
+static int igb_rxnfc_write_etype_filter(struct igb_adapter *adapter,
+					struct igb_nfc_filter *input)
+{
+	struct e1000_hw *hw = &adapter->hw;
+	u8 i;
+	u32 etqf;
+	u16 etype;
+
+	/* find an empty etype filter register */
+	for (i = 0; i < MAX_ETYPE_FILTER; ++i) {
+		if (!adapter->etype_bitmap[i])
+			break;
+	}
+	if (i == MAX_ETYPE_FILTER) {
+		dev_err(&adapter->pdev->dev, "ethtool -N: etype filters are all used.\n");
+		return -EINVAL;
+	}
+
+	adapter->etype_bitmap[i] = true;
+
+	etqf = rd32(E1000_ETQF(i));
+	etype = ntohs(input->filter.etype & ETHER_TYPE_FULL_MASK);
+
+	etqf |= E1000_ETQF_FILTER_ENABLE;
+	etqf &= ~E1000_ETQF_ETYPE_MASK;
+	etqf |= (etype & E1000_ETQF_ETYPE_MASK);
+
+	etqf &= ~E1000_ETQF_QUEUE_MASK;
+	etqf |= ((input->action << E1000_ETQF_QUEUE_SHIFT)
+		& E1000_ETQF_QUEUE_MASK);
+	etqf |= E1000_ETQF_QUEUE_ENABLE;
+
+	wr32(E1000_ETQF(i), etqf);
+
+	input->etype_reg_index = i;
+
+	return 0;
+}
+
 int igb_add_filter(struct igb_adapter *adapter, struct igb_nfc_filter *input)
 {
-	return -EINVAL;
+	int err = -EINVAL;
+
+	if (input->filter.match_flags & IGB_FILTER_FLAG_ETHER_TYPE)
+		err = igb_rxnfc_write_etype_filter(adapter, input);
+
+	return err;
+}
+
+static void igb_clear_etype_filter_regs(struct igb_adapter *adapter,
+					u16 reg_index)
+{
+	struct e1000_hw *hw = &adapter->hw;
+	u32 etqf = rd32(E1000_ETQF(reg_index));
+
+	etqf &= ~E1000_ETQF_QUEUE_ENABLE;
+	etqf &= ~E1000_ETQF_QUEUE_MASK;
+	etqf &= ~E1000_ETQF_FILTER_ENABLE;
+
+	wr32(E1000_ETQF(reg_index), etqf);
+
+	adapter->etype_bitmap[reg_index] = false;
 }
 
 int igb_erase_filter(struct igb_adapter *adapter, struct igb_nfc_filter *input)
 {
+	if (input->filter.match_flags & IGB_FILTER_FLAG_ETHER_TYPE)
+		igb_clear_etype_filter_regs(adapter,
+					    input->etype_reg_index);
 	return 0;
 }
 
@@ -2738,10 +2808,15 @@ static int igb_add_ethtool_nfc_entry(struct igb_adapter *adapter,
 	if ((fsp->flow_type & ~FLOW_EXT) != ETHER_FLOW)
 		return -EINVAL;
 
+	if (fsp->m_u.ether_spec.h_proto != ETHER_TYPE_FULL_MASK)
+		return -EINVAL;
+
 	input = kzalloc(sizeof(*input), GFP_KERNEL);
 	if (!input)
 		return -ENOMEM;
 
+	input->filter.etype = fsp->h_u.ether_spec.h_proto;
+	input->filter.match_flags = IGB_FILTER_FLAG_ETHER_TYPE;
 	input->action = fsp->ring_cookie;
 	input->sw_idx = fsp->location;
 
diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c b/drivers/net/ethernet/intel/igb/igb_ptp.c
index f097c5a..83cc151 100644
--- a/drivers/net/ethernet/intel/igb/igb_ptp.c
+++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
@@ -977,12 +977,12 @@ static int igb_ptp_set_timestamp_mode(struct igb_adapter *adapter,
 
 	/* define ethertype filter for timestamped packets */
 	if (is_l2)
-		wr32(E1000_ETQF(3),
+		wr32(E1000_ETQF(IGB_ETQF_FILTER_1588),
 		     (E1000_ETQF_FILTER_ENABLE | /* enable filter */
 		      E1000_ETQF_1588 | /* enable timestamping */
 		      ETH_P_1588));     /* 1588 eth protocol type */
 	else
-		wr32(E1000_ETQF(3), 0);
+		wr32(E1000_ETQF(IGB_ETQF_FILTER_1588), 0);
 
 	/* L4 Queue Filter[3]: filter by destination port and protocol */
 	if (is_l4) {
-- 
2.7.2

[Intel-wired-lan] [PATCH net-next v5 3/4] igb: support RX flow classification by VLAN priority

[Gangfeng]

From: Gangfeng Huang <gangfeng.huang@ni.com>

This patch is meant to allow for RX network flow classification to insert
and remove VLAN priority filter by ethtool

Example:
Add an VLAN priority filter:
$ ethtool -N eth0 flow-type ether vlan 0x6000 vlan-mask 0x1FFF action 2 loc 1

Show all filters:
$ ethtool -n eth0
4 RX rings available
Total 1 rules

Filter: 1
	Flow Type: Raw Ethernet
	Src MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF
	Dest MAC addr: 00:00:00:00:00:00 mask: FF:FF:FF:FF:FF:FF
	Ethertype: 0x0 mask: 0xFFFF
	VLAN EtherType: 0x0 mask: 0xffff
	VLAN: 0x6000 mask: 0x1fff
	User-defined: 0x0 mask: 0xffffffffffffffff
	Action: Direct to queue 2

Delete the filter by location:
$ ethtool -N delete 1

Signed-off-by: Ruhao Gao <ruhao.gao@ni.com>
Signed-off-by: Gangfeng Huang <gangfeng.huang@ni.com>
---
 drivers/net/ethernet/intel/igb/e1000_defines.h |  4 ++
 drivers/net/ethernet/intel/igb/e1000_regs.h    |  1 +
 drivers/net/ethernet/intel/igb/igb.h           |  3 +
 drivers/net/ethernet/intel/igb/igb_ethtool.c   | 91 ++++++++++++++++++++++++--
 4 files changed, 92 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/intel/igb/e1000_defines.h b/drivers/net/ethernet/intel/igb/e1000_defines.h
index 2997c44..cf3846b 100644
--- a/drivers/net/ethernet/intel/igb/e1000_defines.h
+++ b/drivers/net/ethernet/intel/igb/e1000_defines.h
@@ -1024,4 +1024,8 @@
 #define E1000_RTTBCNRC_RF_INT_MASK	\
 	(E1000_RTTBCNRC_RF_DEC_MASK << E1000_RTTBCNRC_RF_INT_SHIFT)
 
+#define E1000_VLAPQF_QUEUE_SEL(_n, q_idx) (q_idx << ((_n) * 4))
+#define E1000_VLAPQF_P_VALID(_n)          (0x1 << (3 + (_n) * 4))
+#define E1000_VLAPQF_QUEUE_MASK           0x03
+
 #endif
diff --git a/drivers/net/ethernet/intel/igb/e1000_regs.h b/drivers/net/ethernet/intel/igb/e1000_regs.h
index 21d9d02..9b66b6f 100644
--- a/drivers/net/ethernet/intel/igb/e1000_regs.h
+++ b/drivers/net/ethernet/intel/igb/e1000_regs.h
@@ -309,6 +309,7 @@
 					(0x054E0 + ((_i - 16) * 8)))
 #define E1000_RAH(_i)  (((_i) <= 15) ? (0x05404 + ((_i) * 8)) : \
 					(0x054E4 + ((_i - 16) * 8)))
+#define E1000_VLAPQF   0x055B0  /* VLAN Priority Queue Filter VLAPQF */
 #define E1000_IP4AT_REG(_i)     (0x05840 + ((_i) * 8))
 #define E1000_IP6AT_REG(_i)     (0x05880 + ((_i) * 4))
 #define E1000_WUPM_REG(_i)      (0x05A00 + ((_i) * 4))
diff --git a/drivers/net/ethernet/intel/igb/igb.h b/drivers/net/ethernet/intel/igb/igb.h
index 9bdc8a8..293eae5 100644
--- a/drivers/net/ethernet/intel/igb/igb.h
+++ b/drivers/net/ethernet/intel/igb/igb.h
@@ -371,6 +371,7 @@ struct hwmon_buff {
 
 enum igb_filter_match_flags {
 	IGB_FILTER_FLAG_ETHER_TYPE  = 0x1,
+	IGB_FILTER_FLAG_VLAN_TCI    = 0x2,
 };
 
 #define IGB_MAX_RXNFC_FILTERS 16
@@ -380,9 +381,11 @@ struct igb_nfc_input {
 	/* Byte layout in order, all values with MSB first:
 	* match_flags - 1 byte
 	* etype       - 2 bytes
+	* vlan_tci    - 2 bytes
 	*/
 	u8     match_flags;
 	__be16 etype;
+	__be16 vlan_tci;
 };
 
 struct igb_nfc_filter {
diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 00e3387..5ebaca8 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -2449,11 +2449,18 @@ static int igb_get_ethtool_nfc_entry(struct igb_adapter *adapter,
 	if (!rule || fsp->location != rule->sw_idx)
 		return -EINVAL;
 
-	if (rule->filter.match_flags & IGB_FILTER_FLAG_ETHER_TYPE) {
+	if (rule->filter.match_flags) {
 		fsp->flow_type = ETHER_FLOW;
 		fsp->ring_cookie = rule->action;
-		fsp->h_u.ether_spec.h_proto = rule->filter.etype;
-		fsp->m_u.ether_spec.h_proto = ETHER_TYPE_FULL_MASK;
+		if (rule->filter.match_flags & IGB_FILTER_FLAG_ETHER_TYPE) {
+			fsp->h_u.ether_spec.h_proto = rule->filter.etype;
+			fsp->m_u.ether_spec.h_proto = ETHER_TYPE_FULL_MASK;
+		}
+		if (rule->filter.match_flags & IGB_FILTER_FLAG_VLAN_TCI) {
+			fsp->flow_type |= FLOW_EXT;
+			fsp->h_ext.vlan_tci = rule->filter.vlan_tci;
+			fsp->m_ext.vlan_tci = htons(VLAN_PRIO_MASK);
+		}
 		return 0;
 	}
 	return -EINVAL;
@@ -2697,12 +2704,46 @@ static int igb_rxnfc_write_etype_filter(struct igb_adapter *adapter,
 	return 0;
 }
 
+int igb_rxnfc_write_vlan_prio_filter(struct igb_adapter *adapter,
+				     struct igb_nfc_filter *input)
+{
+	struct e1000_hw *hw = &adapter->hw;
+	u32 vlapqf;
+	u8 vlan_priority;
+	u16 queue_index;
+
+	vlapqf = rd32(E1000_VLAPQF);
+	vlan_priority = (ntohs(input->filter.vlan_tci) & VLAN_PRIO_MASK)
+				>> VLAN_PRIO_SHIFT;
+	queue_index = (vlapqf >> (vlan_priority * 4)) & E1000_VLAPQF_QUEUE_MASK;
+
+	/* check whether this vlan prio is already set */
+	if ((vlapqf & E1000_VLAPQF_P_VALID(vlan_priority)) &&
+	    (queue_index != input->action)) {
+		dev_err(&adapter->pdev->dev, "ethtool rxnfc set vlan prio filter failed.\n");
+		return -EEXIST;
+	}
+
+	vlapqf |= E1000_VLAPQF_P_VALID(vlan_priority);
+	vlapqf |= E1000_VLAPQF_QUEUE_SEL(vlan_priority, input->action);
+
+	wr32(E1000_VLAPQF, vlapqf);
+
+	return 0;
+}
+
 int igb_add_filter(struct igb_adapter *adapter, struct igb_nfc_filter *input)
 {
 	int err = -EINVAL;
 
-	if (input->filter.match_flags & IGB_FILTER_FLAG_ETHER_TYPE)
+	if (input->filter.match_flags & IGB_FILTER_FLAG_ETHER_TYPE) {
 		err = igb_rxnfc_write_etype_filter(adapter, input);
+		if (err)
+			return err;
+	}
+
+	if (input->filter.match_flags & IGB_FILTER_FLAG_VLAN_TCI)
+		err = igb_rxnfc_write_vlan_prio_filter(adapter, input);
 
 	return err;
 }
@@ -2722,11 +2763,33 @@ static void igb_clear_etype_filter_regs(struct igb_adapter *adapter,
 	adapter->etype_bitmap[reg_index] = false;
 }
 
+static void igb_clear_vlan_prio_filter(struct igb_adapter *adapter,
+				       u16 vlan_tci)
+{
+	struct e1000_hw *hw = &adapter->hw;
+	u32 vlapqf;
+	u8 vlan_priority;
+
+	vlan_priority = (vlan_tci & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
+
+	vlapqf = rd32(E1000_VLAPQF);
+	vlapqf &= ~E1000_VLAPQF_P_VALID(vlan_priority);
+	vlapqf &= ~E1000_VLAPQF_QUEUE_SEL(vlan_priority,
+						E1000_VLAPQF_QUEUE_MASK);
+
+	wr32(E1000_VLAPQF, vlapqf);
+}
+
 int igb_erase_filter(struct igb_adapter *adapter, struct igb_nfc_filter *input)
 {
 	if (input->filter.match_flags & IGB_FILTER_FLAG_ETHER_TYPE)
 		igb_clear_etype_filter_regs(adapter,
 					    input->etype_reg_index);
+
+	if (input->filter.match_flags & IGB_FILTER_FLAG_VLAN_TCI)
+		igb_clear_vlan_prio_filter(adapter,
+					   ntohs(input->filter.vlan_tci));
+
 	return 0;
 }
 
@@ -2808,15 +2871,28 @@ static int igb_add_ethtool_nfc_entry(struct igb_adapter *adapter,
 	if ((fsp->flow_type & ~FLOW_EXT) != ETHER_FLOW)
 		return -EINVAL;
 
-	if (fsp->m_u.ether_spec.h_proto != ETHER_TYPE_FULL_MASK)
+	if (fsp->m_u.ether_spec.h_proto != ETHER_TYPE_FULL_MASK &&
+	    fsp->m_ext.vlan_tci != htons(VLAN_PRIO_MASK))
 		return -EINVAL;
 
 	input = kzalloc(sizeof(*input), GFP_KERNEL);
 	if (!input)
 		return -ENOMEM;
 
-	input->filter.etype = fsp->h_u.ether_spec.h_proto;
-	input->filter.match_flags = IGB_FILTER_FLAG_ETHER_TYPE;
+	if (fsp->m_u.ether_spec.h_proto == ETHER_TYPE_FULL_MASK) {
+		input->filter.etype = fsp->h_u.ether_spec.h_proto;
+		input->filter.match_flags = IGB_FILTER_FLAG_ETHER_TYPE;
+	}
+
+	if ((fsp->flow_type & FLOW_EXT) && fsp->m_ext.vlan_tci) {
+		if (fsp->m_ext.vlan_tci != htons(VLAN_PRIO_MASK)) {
+			err = -EINVAL;
+			goto err_out;
+		}
+		input->filter.vlan_tci = fsp->h_ext.vlan_tci;
+		input->filter.match_flags |= IGB_FILTER_FLAG_VLAN_TCI;
+	}
+
 	input->action = fsp->ring_cookie;
 	input->sw_idx = fsp->location;
 
@@ -2843,6 +2919,7 @@ static int igb_add_ethtool_nfc_entry(struct igb_adapter *adapter,
 
 err_out_w_lock:
 	spin_unlock(&adapter->nfc_lock);
+err_out:
 	kfree(input);
 	return err;
 }
-- 
2.7.2

[Intel-wired-lan] [PATCH net-next v5 4/4] igb: fix error code in igb_add_ethtool_nfc_entry()

[Gangfeng]

From: Gangfeng Huang <gangfeng.huang@ni.com>

Use error "rmgr: Cannot insert RX class rule: Operation not supported" is
more meaningful than "rmgr: Cannot insert RX class rule: Unknown error 524"

CC: Brown Aaron F <aaron.f.brown@intel.com>
Signed-off-by: Gangfeng Huang <gangfeng.huang@ni.com>
---
 drivers/net/ethernet/intel/igb/igb_ethtool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/igb/igb_ethtool.c b/drivers/net/ethernet/intel/igb/igb_ethtool.c
index 5ebaca8..03c88df 100644
--- a/drivers/net/ethernet/intel/igb/igb_ethtool.c
+++ b/drivers/net/ethernet/intel/igb/igb_ethtool.c
@@ -2851,7 +2851,7 @@ static int igb_add_ethtool_nfc_entry(struct igb_adapter *adapter,
 	int err = 0;
 
 	if (!(netdev->hw_features & NETIF_F_NTUPLE))
-		return -ENOTSUPP;
+		return -EOPNOTSUPP;
 
 	/* Don't allow programming if the action is a queue greater than
 	 * the number of online Rx queues.
-- 
2.7.2

[Intel-wired-lan] [PATCH net-next v5 0/4] igb: enable RX network flow classification

[Jeff Kirsher]

On Mon, 2016-05-09 at 17:27 +0800, Gangfeng wrote:
> After apply this series of patches, igb driver will supports advanced
> RX filter that direct receive packets by flows to different hardware
> queue. Enables tight control on routing a flow in the platform.
> 
> In our product, we use the the RX traffic classification to gurantee the
> PTP(ethertype is 0x88F7) packets won't be flooded by best effort packet.
> PTP packets is always be processed by Linux network stack.
> 
> step 1.?
> ? use the ethertype filter to filter most of packet(0x0800) to HW queue;
> step 2.
> ? Add a rule to forward the PTP packets to another HW queue
> 
> The ethtool commands and options:
> 
> -n --show-nfc
> ?? Retrieves the receive network flow classification configurations
> 
> -N --config-nfc
> ?? Configures the receive network flow classification classification
> 
> Change history of this patches:
> Version 1:
> ? Split the patch to 3 patches for review;
> ? Save the filters and restore them after a reset;
> ? In ethtool command, use key word "proto" to replace "vlan-etype:
> ? Fix bugs
> Version 2:
> ? Rebase the patches on the the latest dev-queue;
> Version 3:
> ? Report a meaningful error code for misoperation;
> Version 4:
> ? Rebase the patches on latest dev-queue;
> ? Update the patch description and code comments;?
> Version 5:
> ? Rebase the patches on latest dev-queue;
> ? Update the patch description;

Based on the issues validation has found with your first patch, I am
dropping your series of patches. ?Please address the issues Aaron found
during validation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160516/6b7d9e6b/attachment-0001.asc>