All of lore.kernel.org
 help / color / mirror / Atom feed
* [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection
@ 2023-02-22 17:09 Jacob Keller
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 01/14] ice: re-order ice_mbx_reset_snapshot function Jacob Keller
                   ` (13 more replies)
  0 siblings, 14 replies; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

The primary motivation of this series is to cleanup and refactor the mailbox
overflow detection logic such that it will work with Scalable IOV. In
addition a few other minor cleanups are done while I was working on the
code in the area.

First, the mailbox overflow functions in ice_vf_mbx.c are refactored to
store the data per-VF as an embedded structure in struct ice_vf, rather than
stored separately as a fixed-size array which only works with Single Root
IOV. This reduces the overall memory footprint when only a handful of VFs
are used.

The overflow detection functions are also cleaned up to reduce the need for
multiple separate calls to determine when to report a VF as potentially
malicious.

Finally, the ice_is_malicious_vf function is cleaned up and moved into
ice_virtchnl.c since it is not Single Root IOV specific, and thus does not
belong in ice_sriov.c

I could probably have done this in fewer patches, but I split pieces out to
hopefully aid in reviewing the overall sequence of changes. This does cause
some additional thrash as it results in intermediate versions of the
refactor, but I think its worth it for making each step easier to
understand.

Jacob Keller (14):
  ice: re-order ice_mbx_reset_snapshot function
  ice: convert ice_mbx_clear_malvf to void and use WARN
  ice: track malicious VFs in new ice_mbx_vf_info structure
  ice: move VF overflow message count into struct ice_mbx_vf_info
  ice: remove ice_mbx_deinit_snapshot
  ice: merge ice_mbx_report_malvf with ice_mbx_vf_state_handler
  ice: initialize mailbox snapshot earlier in PF init
  ice: declare ice_vc_process_vf_msg in ice_virtchnl.h
  ice: always report VF overflowing mailbox even without PF VSI
  ice: remove unnecessary &array[0] and just use array
  ice: pass mbxdata to ice_is_malicious_vf()
  ice: print message if ice_mbx_vf_state_handler returns an error
  ice: move ice_is_malicious_vf() to ice_virtchnl.c
  ice: call ice_is_malicious_vf() from ice_vc_process_vf_msg()

 drivers/net/ethernet/intel/ice/ice_main.c     |  12 +-
 drivers/net/ethernet/intel/ice/ice_sriov.c    |  77 +-----
 drivers/net/ethernet/intel/ice/ice_sriov.h    |  14 -
 drivers/net/ethernet/intel/ice/ice_type.h     |  17 +-
 drivers/net/ethernet/intel/ice/ice_vf_lib.c   |  15 +-
 drivers/net/ethernet/intel/ice/ice_vf_lib.h   |   2 +-
 drivers/net/ethernet/intel/ice/ice_vf_mbx.c   | 251 ++++++------------
 drivers/net/ethernet/intel/ice/ice_vf_mbx.h   |  17 +-
 drivers/net/ethernet/intel/ice/ice_virtchnl.c |  49 +++-
 drivers/net/ethernet/intel/ice/ice_virtchnl.h |   8 +
 10 files changed, 165 insertions(+), 297 deletions(-)


base-commit: c6ce92e9dcb102b82599f9be908c3a9ad815d6dd
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 01/14] ice: re-order ice_mbx_reset_snapshot function
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:15   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 02/14] ice: convert ice_mbx_clear_malvf to void and use WARN Jacob Keller
                   ` (12 subsequent siblings)
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

A future change is going to refactor the VF mailbox overflow detection
logic, including modifying ice_mbx_reset_snapshot and its callers. To make
this change easier to review, first move the ice_mbx_reset_snapshot
function higher in the ice_vf_mbx.c file.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 48 ++++++++++-----------
 1 file changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
index f56fa94ff3d0..2fe9a9504914 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
@@ -130,6 +130,30 @@ u32 ice_conv_link_speed_to_virtchnl(bool adv_link_support, u16 link_speed)
  */
 #define ICE_IGNORE_MAX_MSG_CNT	0xFFFF
 
+/**
+ * ice_mbx_reset_snapshot - Reset mailbox snapshot structure
+ * @snap: pointer to mailbox snapshot structure in the ice_hw struct
+ *
+ * Reset the mailbox snapshot structure and clear VF counter array.
+ */
+static void ice_mbx_reset_snapshot(struct ice_mbx_snapshot *snap)
+{
+	u32 vfcntr_len;
+
+	if (!snap || !snap->mbx_vf.vf_cntr)
+		return;
+
+	/* Clear VF counters. */
+	vfcntr_len = snap->mbx_vf.vfcntr_len;
+	if (vfcntr_len)
+		memset(snap->mbx_vf.vf_cntr, 0,
+		       (vfcntr_len * sizeof(*snap->mbx_vf.vf_cntr)));
+
+	/* Reset mailbox snapshot for a new capture. */
+	memset(&snap->mbx_buf, 0, sizeof(snap->mbx_buf));
+	snap->mbx_buf.state = ICE_MAL_VF_DETECT_STATE_NEW_SNAPSHOT;
+}
+
 /**
  * ice_mbx_traverse - Pass through mailbox snapshot
  * @hw: pointer to the HW struct
@@ -201,30 +225,6 @@ ice_mbx_detect_malvf(struct ice_hw *hw, u16 vf_id,
 	return 0;
 }
 
-/**
- * ice_mbx_reset_snapshot - Reset mailbox snapshot structure
- * @snap: pointer to mailbox snapshot structure in the ice_hw struct
- *
- * Reset the mailbox snapshot structure and clear VF counter array.
- */
-static void ice_mbx_reset_snapshot(struct ice_mbx_snapshot *snap)
-{
-	u32 vfcntr_len;
-
-	if (!snap || !snap->mbx_vf.vf_cntr)
-		return;
-
-	/* Clear VF counters. */
-	vfcntr_len = snap->mbx_vf.vfcntr_len;
-	if (vfcntr_len)
-		memset(snap->mbx_vf.vf_cntr, 0,
-		       (vfcntr_len * sizeof(*snap->mbx_vf.vf_cntr)));
-
-	/* Reset mailbox snapshot for a new capture. */
-	memset(&snap->mbx_buf, 0, sizeof(snap->mbx_buf));
-	snap->mbx_buf.state = ICE_MAL_VF_DETECT_STATE_NEW_SNAPSHOT;
-}
-
 /**
  * ice_mbx_vf_state_handler - Handle states of the overflow algorithm
  * @hw: pointer to the HW struct

base-commit: 3a127e58112af46ebf9922a0cc2e52146bc931a4
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 02/14] ice: convert ice_mbx_clear_malvf to void and use WARN
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 01/14] ice: re-order ice_mbx_reset_snapshot function Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:15   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 03/14] ice: track malicious VFs in new ice_mbx_vf_info structure Jacob Keller
                   ` (11 subsequent siblings)
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

The ice_mbx_clear_malvf function checks for a few error conditions before
clearing the appropriate data. These error conditions are really warnings
that should never occur in a properly initialized driver. Every caller of
ice_mbx_clear_malvf just prints a dev_dbg message on failure which will
generally be ignored.

Convert this function to void and switch the error return values to
WARN_ON. This will make any potentially misconfiguration more visible and
makes future refactors that involve changing how we store the malicious VF
data easier.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_sriov.c  |  6 ++----
 drivers/net/ethernet/intel/ice/ice_vf_lib.c | 12 ++++--------
 drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 16 +++++++---------
 drivers/net/ethernet/intel/ice/ice_vf_mbx.h |  2 +-
 4 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 96a64c25e2ef..7107c279752a 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -204,10 +204,8 @@ void ice_free_vfs(struct ice_pf *pf)
 		}
 
 		/* clear malicious info since the VF is getting released */
-		if (ice_mbx_clear_malvf(&hw->mbx_snapshot, pf->vfs.malvfs,
-					ICE_MAX_SRIOV_VFS, vf->vf_id))
-			dev_dbg(dev, "failed to clear malicious VF state for VF %u\n",
-				vf->vf_id);
+		ice_mbx_clear_malvf(&hw->mbx_snapshot, pf->vfs.malvfs,
+				    ICE_MAX_SRIOV_VFS, vf->vf_id);
 
 		mutex_unlock(&vf->cfg_lock);
 	}
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
index 0e57bd1b85fd..116b43588389 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
@@ -496,10 +496,8 @@ void ice_reset_all_vfs(struct ice_pf *pf)
 
 	/* clear all malicious info if the VFs are getting reset */
 	ice_for_each_vf(pf, bkt, vf)
-		if (ice_mbx_clear_malvf(&hw->mbx_snapshot, pf->vfs.malvfs,
-					ICE_MAX_SRIOV_VFS, vf->vf_id))
-			dev_dbg(dev, "failed to clear malicious VF state for VF %u\n",
-				vf->vf_id);
+		ice_mbx_clear_malvf(&hw->mbx_snapshot, pf->vfs.malvfs,
+				    ICE_MAX_SRIOV_VFS, vf->vf_id);
 
 	/* If VFs have been disabled, there is no need to reset */
 	if (test_and_set_bit(ICE_VF_DIS, pf->state)) {
@@ -705,10 +703,8 @@ int ice_reset_vf(struct ice_vf *vf, u32 flags)
 	ice_eswitch_replay_vf_mac_rule(vf);
 
 	/* if the VF has been reset allow it to come up again */
-	if (ice_mbx_clear_malvf(&hw->mbx_snapshot, pf->vfs.malvfs,
-				ICE_MAX_SRIOV_VFS, vf->vf_id))
-		dev_dbg(dev, "failed to clear malicious VF state for VF %u\n",
-			vf->vf_id);
+	ice_mbx_clear_malvf(&hw->mbx_snapshot, pf->vfs.malvfs,
+			    ICE_MAX_SRIOV_VFS, vf->vf_id);
 
 out_unlock:
 	if (flags & ICE_VF_RESET_LOCK)
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
index 2fe9a9504914..9f6acfeb0fc6 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
@@ -392,19 +392,19 @@ ice_mbx_report_malvf(struct ice_hw *hw, unsigned long *all_malvfs,
  * that the new VF loaded is not considered malicious before going
  * through the overflow detection algorithm.
  */
-int
+void
 ice_mbx_clear_malvf(struct ice_mbx_snapshot *snap, unsigned long *all_malvfs,
 		    u16 bitmap_len, u16 vf_id)
 {
-	if (!snap || !all_malvfs)
-		return -EINVAL;
+	if (WARN_ON(!snap || !all_malvfs))
+		return;
 
-	if (bitmap_len < snap->mbx_vf.vfcntr_len)
-		return -EINVAL;
+	if (WARN_ON(bitmap_len < snap->mbx_vf.vfcntr_len))
+		return;
 
 	/* Ensure VF ID value is not larger than bitmap or VF counter length */
-	if (vf_id >= bitmap_len || vf_id >= snap->mbx_vf.vfcntr_len)
-		return -EIO;
+	if (WARN_ON(vf_id >= bitmap_len || vf_id >= snap->mbx_vf.vfcntr_len))
+		return;
 
 	/* Clear VF ID bit in the bitmap tracking malicious VFs attached to PF */
 	clear_bit(vf_id, all_malvfs);
@@ -416,8 +416,6 @@ ice_mbx_clear_malvf(struct ice_mbx_snapshot *snap, unsigned long *all_malvfs,
 	 * values in the mailbox overflow detection algorithm.
 	 */
 	snap->mbx_vf.vf_cntr[vf_id] = 0;
-
-	return 0;
 }
 
 /**
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.h b/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
index 582716e6d5f9..be593b951642 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
+++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
@@ -22,7 +22,7 @@ u32 ice_conv_link_speed_to_virtchnl(bool adv_link_support, u16 link_speed);
 int
 ice_mbx_vf_state_handler(struct ice_hw *hw, struct ice_mbx_data *mbx_data,
 			 u16 vf_id, bool *is_mal_vf);
-int
+void
 ice_mbx_clear_malvf(struct ice_mbx_snapshot *snap, unsigned long *all_malvfs,
 		    u16 bitmap_len, u16 vf_id);
 int ice_mbx_init_snapshot(struct ice_hw *hw, u16 vf_count);
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 03/14] ice: track malicious VFs in new ice_mbx_vf_info structure
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 01/14] ice: re-order ice_mbx_reset_snapshot function Jacob Keller
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 02/14] ice: convert ice_mbx_clear_malvf to void and use WARN Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:15   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 04/14] ice: move VF overflow message count into struct ice_mbx_vf_info Jacob Keller
                   ` (10 subsequent siblings)
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

Currently the PF tracks malicious VFs in a malvfs bitmap which is used by
the ice_mbx_clear_malvf and ice_mbx_report_malvf functions. This bitmap is
used to ensure that we only report a VF as malicious once rather than
continuously spamming the event log.

This mechanism of storage for the malicious indication works well enough
for SR-IOV. However, it will not work with Scalable IOV. This is because
Scalable IOV VFs can be allocated dynamically and might change VF ID when
their underlying VSI changes.

To support this, the mailbox overflow logic will need to be refactored.
First, introduce a new ice_mbx_vf_info structure which will be used to
store data about a VF. Embed this structure in the struct ice_vf, and
ensure it gets initialized when a new VF is created.

For now this only stores the malicious indicator bit. Pass a pointer to the
VF's mbx_info structure instead of using a bitmap to keep track of these
bits.

A future change will extend this structure and the rest of the logic
associated with the overflow detection.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_sriov.c  |  7 +-
 drivers/net/ethernet/intel/ice/ice_type.h   |  7 ++
 drivers/net/ethernet/intel/ice/ice_vf_lib.c | 10 +--
 drivers/net/ethernet/intel/ice/ice_vf_lib.h |  2 +-
 drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 71 +++++++++------------
 drivers/net/ethernet/intel/ice/ice_vf_mbx.h |  9 +--
 6 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 7107c279752a..44b94276df91 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -204,8 +204,8 @@ void ice_free_vfs(struct ice_pf *pf)
 		}
 
 		/* clear malicious info since the VF is getting released */
-		ice_mbx_clear_malvf(&hw->mbx_snapshot, pf->vfs.malvfs,
-				    ICE_MAX_SRIOV_VFS, vf->vf_id);
+		ice_mbx_clear_malvf(&hw->mbx_snapshot, vf->vf_id,
+				    &vf->mbx_info);
 
 		mutex_unlock(&vf->cfg_lock);
 	}
@@ -1828,8 +1828,7 @@ ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
 		/* if the VF is malicious and we haven't let the user
 		 * know about it, then let them know now
 		 */
-		status = ice_mbx_report_malvf(&pf->hw, pf->vfs.malvfs,
-					      ICE_MAX_SRIOV_VFS, vf_id,
+		status = ice_mbx_report_malvf(&pf->hw, &vf->mbx_info,
 					      &report_vf);
 		if (status)
 			dev_dbg(dev, "Error reporting malicious VF\n");
diff --git a/drivers/net/ethernet/intel/ice/ice_type.h b/drivers/net/ethernet/intel/ice/ice_type.h
index e3f622cad425..d243a0c59ea4 100644
--- a/drivers/net/ethernet/intel/ice/ice_type.h
+++ b/drivers/net/ethernet/intel/ice/ice_type.h
@@ -794,6 +794,13 @@ struct ice_mbx_vf_counter {
 	u32 vfcntr_len;
 };
 
+/* Structure used to track a single VF's messages on the mailbox:
+ * 1. malicious: whether this VF has been detected as malicious before
+ */
+struct ice_mbx_vf_info {
+	u8 malicious : 1;
+};
+
 /* Structure to hold data relevant to the captured static snapshot
  * of the PF-VF mailbox.
  */
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
index 116b43588389..69e89e960950 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
@@ -496,8 +496,8 @@ void ice_reset_all_vfs(struct ice_pf *pf)
 
 	/* clear all malicious info if the VFs are getting reset */
 	ice_for_each_vf(pf, bkt, vf)
-		ice_mbx_clear_malvf(&hw->mbx_snapshot, pf->vfs.malvfs,
-				    ICE_MAX_SRIOV_VFS, vf->vf_id);
+		ice_mbx_clear_malvf(&hw->mbx_snapshot, vf->vf_id,
+				    &vf->mbx_info);
 
 	/* If VFs have been disabled, there is no need to reset */
 	if (test_and_set_bit(ICE_VF_DIS, pf->state)) {
@@ -703,8 +703,7 @@ int ice_reset_vf(struct ice_vf *vf, u32 flags)
 	ice_eswitch_replay_vf_mac_rule(vf);
 
 	/* if the VF has been reset allow it to come up again */
-	ice_mbx_clear_malvf(&hw->mbx_snapshot, pf->vfs.malvfs,
-			    ICE_MAX_SRIOV_VFS, vf->vf_id);
+	ice_mbx_clear_malvf(&hw->mbx_snapshot, vf->vf_id, &vf->mbx_info);
 
 out_unlock:
 	if (flags & ICE_VF_RESET_LOCK)
@@ -760,6 +759,9 @@ void ice_initialize_vf_entry(struct ice_vf *vf)
 	ice_vf_ctrl_invalidate_vsi(vf);
 	ice_vf_fdir_init(vf);
 
+	/* Initialize mailbox info for this VF */
+	ice_mbx_init_vf_info(&pf->hw, &vf->mbx_info);
+
 	mutex_init(&vf->cfg_lock);
 }
 
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.h b/drivers/net/ethernet/intel/ice/ice_vf_lib.h
index ef30f05b5d02..e3cda6fb71ab 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_lib.h
+++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.h
@@ -74,7 +74,6 @@ struct ice_vfs {
 	u16 num_qps_per;		/* number of queue pairs per VF */
 	u16 num_msix_per;		/* number of MSI-X vectors per VF */
 	unsigned long last_printed_mdd_jiffies;	/* MDD message rate limit */
-	DECLARE_BITMAP(malvfs, ICE_MAX_SRIOV_VFS); /* malicious VF indicator */
 };
 
 /* VF information structure */
@@ -105,6 +104,7 @@ struct ice_vf {
 	DECLARE_BITMAP(rxq_ena, ICE_MAX_RSS_QS_PER_VF);
 	struct ice_vlan port_vlan_info;	/* Port VLAN ID, QoS, and TPID */
 	struct virtchnl_vlan_caps vlan_v2_caps;
+	struct ice_mbx_vf_info mbx_info;
 	u8 pf_set_mac:1;		/* VF MAC address set by VMM admin */
 	u8 trusted:1;
 	u8 spoofchk:1;
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
index 9f6acfeb0fc6..2e769bd0bf7e 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
@@ -345,35 +345,23 @@ ice_mbx_vf_state_handler(struct ice_hw *hw,
 /**
  * ice_mbx_report_malvf - Track and note malicious VF
  * @hw: pointer to the HW struct
- * @all_malvfs: all malicious VFs tracked by PF
- * @bitmap_len: length of bitmap in bits
- * @vf_id: relative virtual function ID of the malicious VF
+ * @vf_info: the mailbox tracking info structure for a VF
  * @report_malvf: boolean to indicate if malicious VF must be reported
  *
- * This function will update a bitmap that keeps track of the malicious
- * VFs attached to the PF. A malicious VF must be reported only once if
- * discovered between VF resets or loading so the function checks
- * the input vf_id against the bitmap to verify if the VF has been
- * detected in any previous mailbox iterations.
+ * This function updates the malicious indicator bit in the VF mailbox
+ * tracking structure. A malicious VF must be reported only once if discovered
+ * between VF resets or loading so the function first checks if the VF has
+ * already been detected in any previous mailbox iterations.
  */
 int
-ice_mbx_report_malvf(struct ice_hw *hw, unsigned long *all_malvfs,
-		     u16 bitmap_len, u16 vf_id, bool *report_malvf)
+ice_mbx_report_malvf(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info,
+		     bool *report_malvf)
 {
-	if (!all_malvfs || !report_malvf)
+	if (!report_malvf)
 		return -EINVAL;
 
-	*report_malvf = false;
-
-	if (bitmap_len < hw->mbx_snapshot.mbx_vf.vfcntr_len)
-		return -EINVAL;
-
-	if (vf_id >= bitmap_len)
-		return -EIO;
-
-	/* If the vf_id is found in the bitmap set bit and boolean to true */
-	if (!test_and_set_bit(vf_id, all_malvfs))
-		*report_malvf = true;
+	*report_malvf = !vf_info->malicious;
+	vf_info->malicious = 1;
 
 	return 0;
 }
@@ -381,33 +369,24 @@ ice_mbx_report_malvf(struct ice_hw *hw, unsigned long *all_malvfs,
 /**
  * ice_mbx_clear_malvf - Clear VF bitmap and counter for VF ID
  * @snap: pointer to the mailbox snapshot structure
- * @all_malvfs: all malicious VFs tracked by PF
- * @bitmap_len: length of bitmap in bits
  * @vf_id: relative virtual function ID of the malicious VF
+ * @vf_info: mailbox tracking structure for this VF
  *
- * In case of a VF reset, this function can be called to clear
- * the bit corresponding to the VF ID in the bitmap tracking all
- * malicious VFs attached to the PF. The function also clears the
- * VF counter array at the index of the VF ID. This is to ensure
- * that the new VF loaded is not considered malicious before going
- * through the overflow detection algorithm.
- */
+* In case of a VF reset, this function shall be called to clear the VF's
+* current mailbox tracking state.
+*/
 void
-ice_mbx_clear_malvf(struct ice_mbx_snapshot *snap, unsigned long *all_malvfs,
-		    u16 bitmap_len, u16 vf_id)
+ice_mbx_clear_malvf(struct ice_mbx_snapshot *snap, u16 vf_id,
+		    struct ice_mbx_vf_info *vf_info)
 {
-	if (WARN_ON(!snap || !all_malvfs))
-		return;
-
-	if (WARN_ON(bitmap_len < snap->mbx_vf.vfcntr_len))
+	if (WARN_ON(!snap))
 		return;
 
 	/* Ensure VF ID value is not larger than bitmap or VF counter length */
-	if (WARN_ON(vf_id >= bitmap_len || vf_id >= snap->mbx_vf.vfcntr_len))
+	if (WARN_ON(vf_id >= snap->mbx_vf.vfcntr_len))
 		return;
 
-	/* Clear VF ID bit in the bitmap tracking malicious VFs attached to PF */
-	clear_bit(vf_id, all_malvfs);
+	vf_info->malicious = 0;
 
 	/* Clear the VF counter in the mailbox snapshot structure for that VF ID.
 	 * This is to ensure that if a VF is unloaded and a new one brought back
@@ -418,6 +397,18 @@ ice_mbx_clear_malvf(struct ice_mbx_snapshot *snap, unsigned long *all_malvfs,
 	snap->mbx_vf.vf_cntr[vf_id] = 0;
 }
 
+/**
+ * ice_mbx_init_vf_info - Initialize a new VF mailbox tracking info
+ * @hw: pointer to the hardware structure
+ * @vf_info: the mailbox tracking info structure for a VF
+ *
+ * Initialize a VF mailbox tracking info structure.
+ */
+void ice_mbx_init_vf_info(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info)
+{
+	vf_info->malicious = 0;
+}
+
 /**
  * ice_mbx_init_snapshot - Initialize mailbox snapshot structure
  * @hw: pointer to the hardware structure
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.h b/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
index be593b951642..2613cba61ac7 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
+++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
@@ -23,13 +23,14 @@ int
 ice_mbx_vf_state_handler(struct ice_hw *hw, struct ice_mbx_data *mbx_data,
 			 u16 vf_id, bool *is_mal_vf);
 void
-ice_mbx_clear_malvf(struct ice_mbx_snapshot *snap, unsigned long *all_malvfs,
-		    u16 bitmap_len, u16 vf_id);
+ice_mbx_clear_malvf(struct ice_mbx_snapshot *snap, u16 vf_id,
+		    struct ice_mbx_vf_info *vf_info);
+void ice_mbx_init_vf_info(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info);
 int ice_mbx_init_snapshot(struct ice_hw *hw, u16 vf_count);
 void ice_mbx_deinit_snapshot(struct ice_hw *hw);
 int
-ice_mbx_report_malvf(struct ice_hw *hw, unsigned long *all_malvfs,
-		     u16 bitmap_len, u16 vf_id, bool *report_malvf);
+ice_mbx_report_malvf(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info,
+		     bool *report_malvf);
 #else /* CONFIG_PCI_IOV */
 static inline int
 ice_aq_send_msg_to_vf(struct ice_hw __always_unused *hw,
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 04/14] ice: move VF overflow message count into struct ice_mbx_vf_info
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
                   ` (2 preceding siblings ...)
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 03/14] ice: track malicious VFs in new ice_mbx_vf_info structure Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:16   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 05/14] ice: remove ice_mbx_deinit_snapshot Jacob Keller
                   ` (9 subsequent siblings)
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

The ice driver has some logic in ice_vf_mbx.c used to detect potentially
malicious VF behavior with regards to overflowing the PF mailbox. This
logic currently stores message counts in struct ice_mbx_vf_counter.vf_cntr
as an array. This array is allocated during initialization with
ice_mbx_init_snapshot.

This logic makes sense for SR-IOV where all VFs are allocated at once up
front. However, in the future with Scalable IOV this logic will not work.
VFs can be added and removed dynamically. We could try to keep the vf_cntr
array for the maximum possible number of VFs, but this is a waste of
memory.

Use the recently introduced struct ice_mbx_vf_info structure to store the
message count. Pass a pointer to the mbx_info for a VF instead of using its
VF ID. Replace the array of VF message counts with a linked list that
tracks all currently active mailbox tracking info structures.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_sriov.c  |   9 +-
 drivers/net/ethernet/intel/ice/ice_type.h   |  18 +--
 drivers/net/ethernet/intel/ice/ice_vf_lib.c |   7 +-
 drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 167 +++++++-------------
 drivers/net/ethernet/intel/ice/ice_vf_mbx.h |   8 +-
 5 files changed, 69 insertions(+), 140 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 44b94276df91..8820f269bfdf 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -204,8 +204,7 @@ void ice_free_vfs(struct ice_pf *pf)
 		}
 
 		/* clear malicious info since the VF is getting released */
-		ice_mbx_clear_malvf(&hw->mbx_snapshot, vf->vf_id,
-				    &vf->mbx_info);
+		list_del(&vf->mbx_info.list_entry);
 
 		mutex_unlock(&vf->cfg_lock);
 	}
@@ -1025,9 +1024,7 @@ int ice_sriov_configure(struct pci_dev *pdev, int num_vfs)
 		return -EBUSY;
 	}
 
-	err = ice_mbx_init_snapshot(&pf->hw, num_vfs);
-	if (err)
-		return err;
+	ice_mbx_init_snapshot(&pf->hw);
 
 	err = ice_pci_sriov_ena(pf, num_vfs);
 	if (err) {
@@ -1818,7 +1815,7 @@ ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
 	mbxdata.async_watermark_val = ICE_MBX_OVERFLOW_WATERMARK;
 
 	/* check to see if we have a malicious VF */
-	status = ice_mbx_vf_state_handler(&pf->hw, &mbxdata, vf_id, &malvf);
+	status = ice_mbx_vf_state_handler(&pf->hw, &mbxdata, &vf->mbx_info, &malvf);
 	if (status)
 		goto out_put_vf;
 
diff --git a/drivers/net/ethernet/intel/ice/ice_type.h b/drivers/net/ethernet/intel/ice/ice_type.h
index d243a0c59ea4..a09556e57803 100644
--- a/drivers/net/ethernet/intel/ice/ice_type.h
+++ b/drivers/net/ethernet/intel/ice/ice_type.h
@@ -784,20 +784,14 @@ struct ice_mbx_snap_buffer_data {
 	u16 max_num_msgs_mbx;
 };
 
-/* Structure to track messages sent by VFs on mailbox:
- * 1. vf_cntr: a counter array of VFs to track the number of
- * asynchronous messages sent by each VF
- * 2. vfcntr_len: number of entries in VF counter array
- */
-struct ice_mbx_vf_counter {
-	u32 *vf_cntr;
-	u32 vfcntr_len;
-};
-
 /* Structure used to track a single VF's messages on the mailbox:
- * 1. malicious: whether this VF has been detected as malicious before
+ * 1. list_entry: linked list entry node
+ * 2. msg_count: the number of asynchronous messages sent by this VF
+ * 3. malicious: whether this VF has been detected as malicious before
  */
 struct ice_mbx_vf_info {
+	struct list_head list_entry;
+	u32 msg_count;
 	u8 malicious : 1;
 };
 
@@ -806,7 +800,7 @@ struct ice_mbx_vf_info {
  */
 struct ice_mbx_snapshot {
 	struct ice_mbx_snap_buffer_data mbx_buf;
-	struct ice_mbx_vf_counter mbx_vf;
+	struct list_head mbx_vf;
 };
 
 /* Structure to hold data to be used for capturing or updating a
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
index 69e89e960950..89fd6982df09 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
@@ -496,8 +496,7 @@ void ice_reset_all_vfs(struct ice_pf *pf)
 
 	/* clear all malicious info if the VFs are getting reset */
 	ice_for_each_vf(pf, bkt, vf)
-		ice_mbx_clear_malvf(&hw->mbx_snapshot, vf->vf_id,
-				    &vf->mbx_info);
+		ice_mbx_clear_malvf(&vf->mbx_info);
 
 	/* If VFs have been disabled, there is no need to reset */
 	if (test_and_set_bit(ICE_VF_DIS, pf->state)) {
@@ -599,12 +598,10 @@ int ice_reset_vf(struct ice_vf *vf, u32 flags)
 	struct ice_pf *pf = vf->pf;
 	struct ice_vsi *vsi;
 	struct device *dev;
-	struct ice_hw *hw;
 	int err = 0;
 	bool rsd;
 
 	dev = ice_pf_to_dev(pf);
-	hw = &pf->hw;
 
 	if (flags & ICE_VF_RESET_NOTIFY)
 		ice_notify_vf_reset(vf);
@@ -703,7 +700,7 @@ int ice_reset_vf(struct ice_vf *vf, u32 flags)
 	ice_eswitch_replay_vf_mac_rule(vf);
 
 	/* if the VF has been reset allow it to come up again */
-	ice_mbx_clear_malvf(&hw->mbx_snapshot, vf->vf_id, &vf->mbx_info);
+	ice_mbx_clear_malvf(&vf->mbx_info);
 
 out_unlock:
 	if (flags & ICE_VF_RESET_LOCK)
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
index 2e769bd0bf7e..4bfed5fb3a88 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
@@ -93,36 +93,31 @@ u32 ice_conv_link_speed_to_virtchnl(bool adv_link_support, u16 link_speed)
  *
  * 2. When the caller starts processing its mailbox queue in response to an
  * interrupt, the structure ice_mbx_snapshot is expected to be cleared before
- * the algorithm can be run for the first time for that interrupt. This can be
- * done via ice_mbx_reset_snapshot().
+ * the algorithm can be run for the first time for that interrupt. This
+ * requires calling ice_mbx_reset_snapshot() as well as calling
+ * ice_mbx_reset_vf_info() for each VF tracking structure.
  *
  * 3. For every message read by the caller from the MBX Queue, the caller must
  * call the detection algorithm's entry function ice_mbx_vf_state_handler().
  * Before every call to ice_mbx_vf_state_handler() the struct ice_mbx_data is
  * filled as it is required to be passed to the algorithm.
  *
- * 4. Every time a message is read from the MBX queue, a VFId is received which
- * is passed to the state handler. The boolean output is_malvf of the state
- * handler ice_mbx_vf_state_handler() serves as an indicator to the caller
- * whether this VF is malicious or not.
+ * 4. Every time a message is read from the MBX queue, a tracking structure
+ * for the VF must be passed to the state handler. The boolean output
+ * report_malvf from ice_mbx_vf_state_handler() serves as an indicator to the
+ * caller whether it must report this VF as malicious or not.
  *
  * 5. When a VF is identified to be malicious, the caller can send a message
- * to the system administrator. The caller can invoke ice_mbx_report_malvf()
- * to help determine if a malicious VF is to be reported or not. This function
- * requires the caller to maintain a global bitmap to track all malicious VFs
- * and pass that to ice_mbx_report_malvf() along with the VFID which was identified
- * to be malicious by ice_mbx_vf_state_handler().
+ * to the system administrator.
  *
- * 6. The global bitmap maintained by PF can be cleared completely if PF is in
- * reset or the bit corresponding to a VF can be cleared if that VF is in reset.
- * When a VF is shut down and brought back up, we assume that the new VF
- * brought up is not malicious and hence report it if found malicious.
+ * 6. The PF is responsible for maintaining the struct ice_mbx_vf_info
+ * structure for each VF. The PF should clear the VF tracking structure if the
+ * VF is reset. When a VF is shut down and brought back up, we will then
+ * assume that the new VF is not malicious and may report it again if we
+ * detect it again.
  *
  * 7. The function ice_mbx_reset_snapshot() is called to reset the information
  * in ice_mbx_snapshot for every new mailbox interrupt handled.
- *
- * 8. The memory allocated for variables in ice_mbx_snapshot is de-allocated
- * when driver is unloaded.
  */
 #define ICE_RQ_DATA_MASK(rq_data) ((rq_data) & PF_MBX_ARQH_ARQH_M)
 /* Using the highest value for an unsigned 16-bit value 0xFFFF to indicate that
@@ -132,26 +127,21 @@ u32 ice_conv_link_speed_to_virtchnl(bool adv_link_support, u16 link_speed)
 
 /**
  * ice_mbx_reset_snapshot - Reset mailbox snapshot structure
- * @snap: pointer to mailbox snapshot structure in the ice_hw struct
- *
- * Reset the mailbox snapshot structure and clear VF counter array.
+ * @snap: pointer to the mailbox snapshot
  */
 static void ice_mbx_reset_snapshot(struct ice_mbx_snapshot *snap)
 {
-	u32 vfcntr_len;
+	struct ice_mbx_vf_info *vf_info;
 
-	if (!snap || !snap->mbx_vf.vf_cntr)
-		return;
-
-	/* Clear VF counters. */
-	vfcntr_len = snap->mbx_vf.vfcntr_len;
-	if (vfcntr_len)
-		memset(snap->mbx_vf.vf_cntr, 0,
-		       (vfcntr_len * sizeof(*snap->mbx_vf.vf_cntr)));
-
-	/* Reset mailbox snapshot for a new capture. */
+	/* Clear mbx_buf in the mailbox snaphot structure and setting the
+	 * mailbox snapshot state to a new capture.
+	 */
 	memset(&snap->mbx_buf, 0, sizeof(snap->mbx_buf));
 	snap->mbx_buf.state = ICE_MAL_VF_DETECT_STATE_NEW_SNAPSHOT;
+
+	/* Reset message counts for all VFs to zero */
+	list_for_each_entry(vf_info, &snap->mbx_vf, list_entry)
+		vf_info->msg_count = 0;
 }
 
 /**
@@ -195,7 +185,7 @@ ice_mbx_traverse(struct ice_hw *hw,
 /**
  * ice_mbx_detect_malvf - Detect malicious VF in snapshot
  * @hw: pointer to the HW struct
- * @vf_id: relative virtual function ID
+ * @vf_info: mailbox tracking structure for a VF
  * @new_state: new algorithm state
  * @is_malvf: boolean output to indicate if VF is malicious
  *
@@ -204,19 +194,14 @@ ice_mbx_traverse(struct ice_hw *hw,
  * the permissible number of messages to send.
  */
 static int
-ice_mbx_detect_malvf(struct ice_hw *hw, u16 vf_id,
+ice_mbx_detect_malvf(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info,
 		     enum ice_mbx_snapshot_state *new_state,
 		     bool *is_malvf)
 {
-	struct ice_mbx_snapshot *snap = &hw->mbx_snapshot;
+	/* increment the message count for this VF */
+	vf_info->msg_count++;
 
-	if (vf_id >= snap->mbx_vf.vfcntr_len)
-		return -EIO;
-
-	/* increment the message count in the VF array */
-	snap->mbx_vf.vf_cntr[vf_id]++;
-
-	if (snap->mbx_vf.vf_cntr[vf_id] >= ICE_ASYNC_VF_MSG_THRESHOLD)
+	if (vf_info->msg_count >= ICE_ASYNC_VF_MSG_THRESHOLD)
 		*is_malvf = true;
 
 	/* continue to iterate through the mailbox snapshot */
@@ -229,7 +214,7 @@ ice_mbx_detect_malvf(struct ice_hw *hw, u16 vf_id,
  * ice_mbx_vf_state_handler - Handle states of the overflow algorithm
  * @hw: pointer to the HW struct
  * @mbx_data: pointer to structure containing mailbox data
- * @vf_id: relative virtual function (VF) ID
+ * @vf_info: mailbox tracking structure for the VF in question
  * @is_malvf: boolean output to indicate if VF is malicious
  *
  * The function serves as an entry point for the malicious VF
@@ -250,7 +235,8 @@ ice_mbx_detect_malvf(struct ice_hw *hw, u16 vf_id,
  */
 int
 ice_mbx_vf_state_handler(struct ice_hw *hw,
-			 struct ice_mbx_data *mbx_data, u16 vf_id,
+			 struct ice_mbx_data *mbx_data,
+			 struct ice_mbx_vf_info *vf_info,
 			 bool *is_malvf)
 {
 	struct ice_mbx_snapshot *snap = &hw->mbx_snapshot;
@@ -315,7 +301,8 @@ ice_mbx_vf_state_handler(struct ice_hw *hw,
 		if (snap_buf->num_pending_arq >=
 		    mbx_data->async_watermark_val) {
 			new_state = ICE_MAL_VF_DETECT_STATE_DETECT;
-			status = ice_mbx_detect_malvf(hw, vf_id, &new_state, is_malvf);
+			status = ice_mbx_detect_malvf(hw, vf_info, &new_state,
+						      is_malvf);
 		} else {
 			new_state = ICE_MAL_VF_DETECT_STATE_TRAVERSE;
 			ice_mbx_traverse(hw, &new_state);
@@ -329,7 +316,8 @@ ice_mbx_vf_state_handler(struct ice_hw *hw,
 
 	case ICE_MAL_VF_DETECT_STATE_DETECT:
 		new_state = ICE_MAL_VF_DETECT_STATE_DETECT;
-		status = ice_mbx_detect_malvf(hw, vf_id, &new_state, is_malvf);
+		status = ice_mbx_detect_malvf(hw, vf_info, &new_state,
+					      is_malvf);
 		break;
 
 	default:
@@ -367,34 +355,16 @@ ice_mbx_report_malvf(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info,
 }
 
 /**
- * ice_mbx_clear_malvf - Clear VF bitmap and counter for VF ID
- * @snap: pointer to the mailbox snapshot structure
- * @vf_id: relative virtual function ID of the malicious VF
- * @vf_info: mailbox tracking structure for this VF
+ * ice_mbx_clear_malvf - Clear VF mailbox info
+ * @vf_info: the mailbox tracking structure for a VF
  *
-* In case of a VF reset, this function shall be called to clear the VF's
-* current mailbox tracking state.
-*/
-void
-ice_mbx_clear_malvf(struct ice_mbx_snapshot *snap, u16 vf_id,
-		    struct ice_mbx_vf_info *vf_info)
+ * In case of a VF reset, this function shall be called to clear the VF's
+ * current mailbox tracking state.
+ */
+void ice_mbx_clear_malvf(struct ice_mbx_vf_info *vf_info)
 {
-	if (WARN_ON(!snap))
-		return;
-
-	/* Ensure VF ID value is not larger than bitmap or VF counter length */
-	if (WARN_ON(vf_id >= snap->mbx_vf.vfcntr_len))
-		return;
-
 	vf_info->malicious = 0;
-
-	/* Clear the VF counter in the mailbox snapshot structure for that VF ID.
-	 * This is to ensure that if a VF is unloaded and a new one brought back
-	 * up with the same VF ID for a snapshot currently in traversal or detect
-	 * state the counter for that VF ID does not increment on top of existing
-	 * values in the mailbox overflow detection algorithm.
-	 */
-	snap->mbx_vf.vf_cntr[vf_id] = 0;
+	vf_info->msg_count = 0;
 }
 
 /**
@@ -402,55 +372,32 @@ ice_mbx_clear_malvf(struct ice_mbx_snapshot *snap, u16 vf_id,
  * @hw: pointer to the hardware structure
  * @vf_info: the mailbox tracking info structure for a VF
  *
- * Initialize a VF mailbox tracking info structure.
+ * Initialize a VF mailbox tracking info structure and insert it into the
+ * snapshot list.
+ *
+ * If you remove the VF, you must also delete the associated VF info structure
+ * from the linked list.
  */
 void ice_mbx_init_vf_info(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info)
 {
-	vf_info->malicious = 0;
+	struct ice_mbx_snapshot *snap = &hw->mbx_snapshot;
+
+	ice_mbx_clear_malvf(vf_info);
+	list_add(&vf_info->list_entry, &snap->mbx_vf);
 }
 
 /**
- * ice_mbx_init_snapshot - Initialize mailbox snapshot structure
+ * ice_mbx_init_snapshot - Initialize mailbox snapshot data
  * @hw: pointer to the hardware structure
- * @vf_count: number of VFs allocated on a PF
  *
- * Clear the mailbox snapshot structure and allocate memory
- * for the VF counter array based on the number of VFs allocated
- * on that PF.
- *
- * Assumption: This function will assume ice_get_caps() has already been
- * called to ensure that the vf_count can be compared against the number
- * of VFs supported as defined in the functional capabilities of the device.
+ * Clear the mailbox snapshot structure and initialize the VF mailbox list.
  */
-int ice_mbx_init_snapshot(struct ice_hw *hw, u16 vf_count)
+void ice_mbx_init_snapshot(struct ice_hw *hw)
 {
 	struct ice_mbx_snapshot *snap = &hw->mbx_snapshot;
 
-	/* Ensure that the number of VFs allocated is non-zero and
-	 * is not greater than the number of supported VFs defined in
-	 * the functional capabilities of the PF.
-	 */
-	if (!vf_count || vf_count > hw->func_caps.num_allocd_vfs)
-		return -EINVAL;
-
-	snap->mbx_vf.vf_cntr = devm_kcalloc(ice_hw_to_dev(hw), vf_count,
-					    sizeof(*snap->mbx_vf.vf_cntr),
-					    GFP_KERNEL);
-	if (!snap->mbx_vf.vf_cntr)
-		return -ENOMEM;
-
-	/* Setting the VF counter length to the number of allocated
-	 * VFs for given PF's functional capabilities.
-	 */
-	snap->mbx_vf.vfcntr_len = vf_count;
-
-	/* Clear mbx_buf in the mailbox snaphot structure and setting the
-	 * mailbox snapshot state to a new capture.
-	 */
-	memset(&snap->mbx_buf, 0, sizeof(snap->mbx_buf));
-	snap->mbx_buf.state = ICE_MAL_VF_DETECT_STATE_NEW_SNAPSHOT;
-
-	return 0;
+	INIT_LIST_HEAD(&snap->mbx_vf);
+	ice_mbx_reset_snapshot(snap);
 }
 
 /**
@@ -463,10 +410,6 @@ void ice_mbx_deinit_snapshot(struct ice_hw *hw)
 {
 	struct ice_mbx_snapshot *snap = &hw->mbx_snapshot;
 
-	/* Free VF counter array and reset VF counter length */
-	devm_kfree(ice_hw_to_dev(hw), snap->mbx_vf.vf_cntr);
-	snap->mbx_vf.vfcntr_len = 0;
-
 	/* Clear mbx_buf in the mailbox snaphot structure */
 	memset(&snap->mbx_buf, 0, sizeof(snap->mbx_buf));
 }
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.h b/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
index 2613cba61ac7..a6d42f467dc5 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
+++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
@@ -21,12 +21,10 @@ ice_aq_send_msg_to_vf(struct ice_hw *hw, u16 vfid, u32 v_opcode, u32 v_retval,
 u32 ice_conv_link_speed_to_virtchnl(bool adv_link_support, u16 link_speed);
 int
 ice_mbx_vf_state_handler(struct ice_hw *hw, struct ice_mbx_data *mbx_data,
-			 u16 vf_id, bool *is_mal_vf);
-void
-ice_mbx_clear_malvf(struct ice_mbx_snapshot *snap, u16 vf_id,
-		    struct ice_mbx_vf_info *vf_info);
+			 struct ice_mbx_vf_info *vf_info, bool *is_mal_vf);
+void ice_mbx_clear_malvf(struct ice_mbx_vf_info *vf_info);
 void ice_mbx_init_vf_info(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info);
-int ice_mbx_init_snapshot(struct ice_hw *hw, u16 vf_count);
+void ice_mbx_init_snapshot(struct ice_hw *hw);
 void ice_mbx_deinit_snapshot(struct ice_hw *hw);
 int
 ice_mbx_report_malvf(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info,
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 05/14] ice: remove ice_mbx_deinit_snapshot
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
                   ` (3 preceding siblings ...)
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 04/14] ice: move VF overflow message count into struct ice_mbx_vf_info Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:16   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 06/14] ice: merge ice_mbx_report_malvf with ice_mbx_vf_state_handler Jacob Keller
                   ` (8 subsequent siblings)
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

The ice_mbx_deinit_snapshot function's only remaining job is to clear the
previous snapshot data. This snapshot data is initialized when SR-IOV adds
VFs, so it is not necessary to clear this data when removing VFs. Since no
allocation occurs we no longer need to free anything and we can safely
remove this function.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_sriov.c  |  5 +----
 drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 14 --------------
 drivers/net/ethernet/intel/ice/ice_vf_mbx.h |  1 -
 3 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 8820f269bfdf..b65025b51526 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -1014,7 +1014,6 @@ int ice_sriov_configure(struct pci_dev *pdev, int num_vfs)
 	if (!num_vfs) {
 		if (!pci_vfs_assigned(pdev)) {
 			ice_free_vfs(pf);
-			ice_mbx_deinit_snapshot(&pf->hw);
 			if (pf->lag)
 				ice_enable_lag(pf->lag);
 			return 0;
@@ -1027,10 +1026,8 @@ int ice_sriov_configure(struct pci_dev *pdev, int num_vfs)
 	ice_mbx_init_snapshot(&pf->hw);
 
 	err = ice_pci_sriov_ena(pf, num_vfs);
-	if (err) {
-		ice_mbx_deinit_snapshot(&pf->hw);
+	if (err)
 		return err;
-	}
 
 	if (pf->lag)
 		ice_disable_lag(pf->lag);
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
index 4bfed5fb3a88..1f332ab43b00 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
@@ -399,17 +399,3 @@ void ice_mbx_init_snapshot(struct ice_hw *hw)
 	INIT_LIST_HEAD(&snap->mbx_vf);
 	ice_mbx_reset_snapshot(snap);
 }
-
-/**
- * ice_mbx_deinit_snapshot - Free mailbox snapshot structure
- * @hw: pointer to the hardware structure
- *
- * Clear the mailbox snapshot structure and free the VF counter array.
- */
-void ice_mbx_deinit_snapshot(struct ice_hw *hw)
-{
-	struct ice_mbx_snapshot *snap = &hw->mbx_snapshot;
-
-	/* Clear mbx_buf in the mailbox snaphot structure */
-	memset(&snap->mbx_buf, 0, sizeof(snap->mbx_buf));
-}
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.h b/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
index a6d42f467dc5..e4bdd93ccef1 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
+++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
@@ -25,7 +25,6 @@ ice_mbx_vf_state_handler(struct ice_hw *hw, struct ice_mbx_data *mbx_data,
 void ice_mbx_clear_malvf(struct ice_mbx_vf_info *vf_info);
 void ice_mbx_init_vf_info(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info);
 void ice_mbx_init_snapshot(struct ice_hw *hw);
-void ice_mbx_deinit_snapshot(struct ice_hw *hw);
 int
 ice_mbx_report_malvf(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info,
 		     bool *report_malvf);
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 06/14] ice: merge ice_mbx_report_malvf with ice_mbx_vf_state_handler
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
                   ` (4 preceding siblings ...)
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 05/14] ice: remove ice_mbx_deinit_snapshot Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:17   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 07/14] ice: initialize mailbox snapshot earlier in PF init Jacob Keller
                   ` (7 subsequent siblings)
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

The ice_mbx_report_malvf function is used to update the
ice_mbx_vf_info.malicious member after we detect a malicious VF. This is
done by calling ice_mbx_report_malvf after ice_mbx_vf_state_handler sets
its "is_malvf" return parameter true.

Instead of requiring two steps, directly update the malicious bit in the
state handler, and remove the need for separately calling
ice_mbx_report_malvf.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_sriov.c  | 34 +++++---------
 drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 51 ++++++---------------
 drivers/net/ethernet/intel/ice/ice_vf_mbx.h |  5 +-
 3 files changed, 28 insertions(+), 62 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index b65025b51526..71ce3998dd75 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -1794,7 +1794,7 @@ ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
 	s16 vf_id = le16_to_cpu(event->desc.retval);
 	struct device *dev = ice_pf_to_dev(pf);
 	struct ice_mbx_data mbxdata;
-	bool malvf = false;
+	bool report_malvf = false;
 	struct ice_vf *vf;
 	int status;
 
@@ -1811,33 +1811,23 @@ ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
 #define ICE_MBX_OVERFLOW_WATERMARK 64
 	mbxdata.async_watermark_val = ICE_MBX_OVERFLOW_WATERMARK;
 
-	/* check to see if we have a malicious VF */
-	status = ice_mbx_vf_state_handler(&pf->hw, &mbxdata, &vf->mbx_info, &malvf);
+	/* check to see if we have a newly malicious VF */
+	status = ice_mbx_vf_state_handler(&pf->hw, &mbxdata, &vf->mbx_info,
+					  &report_malvf);
 	if (status)
 		goto out_put_vf;
 
-	if (malvf) {
-		bool report_vf = false;
+	if (report_malvf) {
+		struct ice_vsi *pf_vsi = ice_get_main_vsi(pf);
 
-		/* if the VF is malicious and we haven't let the user
-		 * know about it, then let them know now
-		 */
-		status = ice_mbx_report_malvf(&pf->hw, &vf->mbx_info,
-					      &report_vf);
-		if (status)
-			dev_dbg(dev, "Error reporting malicious VF\n");
-
-		if (report_vf) {
-			struct ice_vsi *pf_vsi = ice_get_main_vsi(pf);
-
-			if (pf_vsi)
-				dev_warn(dev, "VF MAC %pM on PF MAC %pM is generating asynchronous messages and may be overflowing the PF message queue. Please see the Adapter User Guide for more information\n",
-					 &vf->dev_lan_addr[0],
-					 pf_vsi->netdev->dev_addr);
-		}
+		if (pf_vsi)
+			dev_warn(dev, "VF MAC %pM on PF MAC %pM is generating asynchronous messages and may be overflowing the PF message queue. Please see the Adapter User Guide for more information\n",
+					&vf->dev_lan_addr[0],
+					pf_vsi->netdev->dev_addr);
 	}
 
 out_put_vf:
 	ice_put_vf(vf);
-	return malvf;
+
+	return vf->mbx_info.malicious;
 }
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
index 1f332ab43b00..15667555589f 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
@@ -215,7 +215,7 @@ ice_mbx_detect_malvf(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info,
  * @hw: pointer to the HW struct
  * @mbx_data: pointer to structure containing mailbox data
  * @vf_info: mailbox tracking structure for the VF in question
- * @is_malvf: boolean output to indicate if VF is malicious
+ * @report_malvf: boolean output to indicate whether VF should be reported
  *
  * The function serves as an entry point for the malicious VF
  * detection algorithm by handling the different states and state
@@ -234,25 +234,24 @@ ice_mbx_detect_malvf(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info,
  * the static snapshot and look for a malicious VF.
  */
 int
-ice_mbx_vf_state_handler(struct ice_hw *hw,
-			 struct ice_mbx_data *mbx_data,
-			 struct ice_mbx_vf_info *vf_info,
-			 bool *is_malvf)
+ice_mbx_vf_state_handler(struct ice_hw *hw, struct ice_mbx_data *mbx_data,
+			 struct ice_mbx_vf_info *vf_info, bool *report_malvf)
 {
 	struct ice_mbx_snapshot *snap = &hw->mbx_snapshot;
 	struct ice_mbx_snap_buffer_data *snap_buf;
 	struct ice_ctl_q_info *cq = &hw->mailboxq;
 	enum ice_mbx_snapshot_state new_state;
 	int status = 0;
+	bool is_malvf = false;
 
-	if (!is_malvf || !mbx_data)
+	if (!report_malvf || !mbx_data || !vf_info)
 		return -EINVAL;
 
+	*report_malvf = false;
+
 	/* When entering the mailbox state machine assume that the VF
 	 * is not malicious until detected.
 	 */
-	*is_malvf = false;
-
 	 /* Checking if max messages allowed to be processed while servicing current
 	  * interrupt is not less than the defined AVF message threshold.
 	  */
@@ -301,8 +300,7 @@ ice_mbx_vf_state_handler(struct ice_hw *hw,
 		if (snap_buf->num_pending_arq >=
 		    mbx_data->async_watermark_val) {
 			new_state = ICE_MAL_VF_DETECT_STATE_DETECT;
-			status = ice_mbx_detect_malvf(hw, vf_info, &new_state,
-						      is_malvf);
+			status = ice_mbx_detect_malvf(hw, vf_info, &new_state, &is_malvf);
 		} else {
 			new_state = ICE_MAL_VF_DETECT_STATE_TRAVERSE;
 			ice_mbx_traverse(hw, &new_state);
@@ -316,8 +314,7 @@ ice_mbx_vf_state_handler(struct ice_hw *hw,
 
 	case ICE_MAL_VF_DETECT_STATE_DETECT:
 		new_state = ICE_MAL_VF_DETECT_STATE_DETECT;
-		status = ice_mbx_detect_malvf(hw, vf_info, &new_state,
-					      is_malvf);
+		status = ice_mbx_detect_malvf(hw, vf_info, &new_state, &is_malvf);
 		break;
 
 	default:
@@ -327,33 +324,15 @@ ice_mbx_vf_state_handler(struct ice_hw *hw,
 
 	snap_buf->state = new_state;
 
+	/* Only report VFs as malicious the first time we detect it */
+	if (is_malvf && !vf_info->malicious) {
+		vf_info->malicious = 1;
+		*report_malvf = true;
+	}
+
 	return status;
 }
 
-/**
- * ice_mbx_report_malvf - Track and note malicious VF
- * @hw: pointer to the HW struct
- * @vf_info: the mailbox tracking info structure for a VF
- * @report_malvf: boolean to indicate if malicious VF must be reported
- *
- * This function updates the malicious indicator bit in the VF mailbox
- * tracking structure. A malicious VF must be reported only once if discovered
- * between VF resets or loading so the function first checks if the VF has
- * already been detected in any previous mailbox iterations.
- */
-int
-ice_mbx_report_malvf(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info,
-		     bool *report_malvf)
-{
-	if (!report_malvf)
-		return -EINVAL;
-
-	*report_malvf = !vf_info->malicious;
-	vf_info->malicious = 1;
-
-	return 0;
-}
-
 /**
  * ice_mbx_clear_malvf - Clear VF mailbox info
  * @vf_info: the mailbox tracking structure for a VF
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.h b/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
index e4bdd93ccef1..41250519bc56 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
+++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
@@ -21,13 +21,10 @@ ice_aq_send_msg_to_vf(struct ice_hw *hw, u16 vfid, u32 v_opcode, u32 v_retval,
 u32 ice_conv_link_speed_to_virtchnl(bool adv_link_support, u16 link_speed);
 int
 ice_mbx_vf_state_handler(struct ice_hw *hw, struct ice_mbx_data *mbx_data,
-			 struct ice_mbx_vf_info *vf_info, bool *is_mal_vf);
+			 struct ice_mbx_vf_info *vf_info, bool *report_malvf);
 void ice_mbx_clear_malvf(struct ice_mbx_vf_info *vf_info);
 void ice_mbx_init_vf_info(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info);
 void ice_mbx_init_snapshot(struct ice_hw *hw);
-int
-ice_mbx_report_malvf(struct ice_hw *hw, struct ice_mbx_vf_info *vf_info,
-		     bool *report_malvf);
 #else /* CONFIG_PCI_IOV */
 static inline int
 ice_aq_send_msg_to_vf(struct ice_hw __always_unused *hw,
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 07/14] ice: initialize mailbox snapshot earlier in PF init
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
                   ` (5 preceding siblings ...)
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 06/14] ice: merge ice_mbx_report_malvf with ice_mbx_vf_state_handler Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:17   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 08/14] ice: declare ice_vc_process_vf_msg in ice_virtchnl.h Jacob Keller
                   ` (6 subsequent siblings)
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

Now that we no longer depend on the number of VFs being allocated, we can
move the ice_mbx_init_snapshot function earlier. This will be required by
Scalable IOV as we will not be calling ice_sriov_configure for Scalable
VFs.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_main.c   | 1 +
 drivers/net/ethernet/intel/ice/ice_sriov.c  | 2 --
 drivers/net/ethernet/intel/ice/ice_vf_mbx.h | 4 ++++
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 567694bf098b..615a731d7afe 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3891,6 +3891,7 @@ static int ice_init_pf(struct ice_pf *pf)
 
 	mutex_init(&pf->vfs.table_lock);
 	hash_init(pf->vfs.table);
+	ice_mbx_init_snapshot(&pf->hw);
 
 	return 0;
 }
diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 71ce3998dd75..6764e677a345 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -1023,8 +1023,6 @@ int ice_sriov_configure(struct pci_dev *pdev, int num_vfs)
 		return -EBUSY;
 	}
 
-	ice_mbx_init_snapshot(&pf->hw);
-
 	err = ice_pci_sriov_ena(pf, num_vfs);
 	if (err)
 		return err;
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.h b/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
index 41250519bc56..44bc030d17e0 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
+++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.h
@@ -43,5 +43,9 @@ ice_conv_link_speed_to_virtchnl(bool __always_unused adv_link_support,
 	return 0;
 }
 
+static inline void ice_mbx_init_snapshot(struct ice_hw *hw)
+{
+}
+
 #endif /* CONFIG_PCI_IOV */
 #endif /* _ICE_VF_MBX_H_ */
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 08/14] ice: declare ice_vc_process_vf_msg in ice_virtchnl.h
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
                   ` (6 preceding siblings ...)
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 07/14] ice: initialize mailbox snapshot earlier in PF init Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:17   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 09/14] ice: always report VF overflowing mailbox even without PF VSI Jacob Keller
                   ` (5 subsequent siblings)
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

The ice_vc_process_vf_msg function is the main entry point for handling
virtchnl messages. This function is defined in ice_virtchnl.c but its
declaration is still in ice_sriov.c

The ice_sriov.c file used to contain all of the virtualization logic until
commit bf93bf791cec ("ice: introduce ice_virtchnl.c and ice_virtchnl.h")
moved the virtchnl logic to its own file.

The ice_vc_process_vf_msg function should have had its declaration moved to
ice_virtchnl.h then. Fix this.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_sriov.h    | 3 ---
 drivers/net/ethernet/intel/ice/ice_virtchnl.h | 6 ++++++
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.h b/drivers/net/ethernet/intel/ice/ice_sriov.h
index 955ab810a198..1082b0691a3f 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.h
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.h
@@ -33,7 +33,6 @@ int
 ice_get_vf_cfg(struct net_device *netdev, int vf_id, struct ifla_vf_info *ivi);
 
 void ice_free_vfs(struct ice_pf *pf);
-void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event);
 void ice_restore_all_vfs_msi_state(struct pci_dev *pdev);
 bool
 ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
@@ -68,8 +67,6 @@ ice_vc_validate_pattern(struct ice_vf *vf, struct virtchnl_proto_hdrs *proto);
 static inline void ice_process_vflr_event(struct ice_pf *pf) { }
 static inline void ice_free_vfs(struct ice_pf *pf) { }
 static inline
-void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event) { }
-static inline
 void ice_vf_lan_overflow_event(struct ice_pf *pf, struct ice_rq_event_info *event) { }
 static inline void ice_print_vfs_mdd_events(struct ice_pf *pf) { }
 static inline void ice_print_vf_rx_mdd_event(struct ice_vf *vf) { }
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.h b/drivers/net/ethernet/intel/ice/ice_virtchnl.h
index b454654d7b0c..6d5af29c855e 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl.h
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.h
@@ -63,6 +63,7 @@ int
 ice_vc_send_msg_to_vf(struct ice_vf *vf, u32 v_opcode,
 		      enum virtchnl_status_code v_retval, u8 *msg, u16 msglen);
 bool ice_vc_isvalid_vsi_id(struct ice_vf *vf, u16 vsi_id);
+void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event);
 #else /* CONFIG_PCI_IOV */
 static inline void ice_virtchnl_set_dflt_ops(struct ice_vf *vf) { }
 static inline void ice_virtchnl_set_repr_ops(struct ice_vf *vf) { }
@@ -81,6 +82,11 @@ static inline bool ice_vc_isvalid_vsi_id(struct ice_vf *vf, u16 vsi_id)
 {
 	return false;
 }
+
+static inline void
+ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
+{
+}
 #endif /* !CONFIG_PCI_IOV */
 
 #endif /* _ICE_VIRTCHNL_H_ */
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 09/14] ice: always report VF overflowing mailbox even without PF VSI
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
                   ` (7 preceding siblings ...)
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 08/14] ice: declare ice_vc_process_vf_msg in ice_virtchnl.h Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:17   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 10/14] ice: remove unnecessary &array[0] and just use array Jacob Keller
                   ` (4 subsequent siblings)
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

In ice_is_malicious_vf we report a message warning the system administrator
when a VF is potentially spamming the PF with asynchronous messages that
could overflow the PF mailbox.

The specific message was requested by our customer support team to include
the VF and PF MAC address. In some cases we may not be able to locate the
PF VSI to obtain the MAC address for the PF. The current implementation
discards the message entirely in this case. Fix this to instead print a
zero address in that case so that we always print something here. Note that
dev_warn will also include the PCI device information allowing another
mechanism for determining on which PF the potentially malicious VF belongs.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_sriov.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 6764e677a345..185673afb781 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -1817,11 +1817,11 @@ ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
 
 	if (report_malvf) {
 		struct ice_vsi *pf_vsi = ice_get_main_vsi(pf);
+		u8 zero_addr[ETH_ALEN] = {};
 
-		if (pf_vsi)
-			dev_warn(dev, "VF MAC %pM on PF MAC %pM is generating asynchronous messages and may be overflowing the PF message queue. Please see the Adapter User Guide for more information\n",
-					&vf->dev_lan_addr[0],
-					pf_vsi->netdev->dev_addr);
+		dev_warn(dev, "VF MAC %pM on PF MAC %pM is generating asynchronous messages and may be overflowing the PF message queue. Please see the Adapter User Guide for more information\n",
+			 &vf->dev_lan_addr[0],
+			 pf_vsi ? pf_vsi->netdev->dev_addr : zero_addr);
 	}
 
 out_put_vf:
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 10/14] ice: remove unnecessary &array[0] and just use array
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
                   ` (8 preceding siblings ...)
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 09/14] ice: always report VF overflowing mailbox even without PF VSI Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:18   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 11/14] ice: pass mbxdata to ice_is_malicious_vf() Jacob Keller
                   ` (3 subsequent siblings)
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

In ice_is_malicious_vf we print the VF MAC address using %pM by passing the
address of the first element of vf->dev_lan_addr. This is equivalent to
just passing vf->dev_lan_addr, so do that.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_sriov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 185673afb781..938be486721e 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -1820,7 +1820,7 @@ ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
 		u8 zero_addr[ETH_ALEN] = {};
 
 		dev_warn(dev, "VF MAC %pM on PF MAC %pM is generating asynchronous messages and may be overflowing the PF message queue. Please see the Adapter User Guide for more information\n",
-			 &vf->dev_lan_addr[0],
+			 vf->dev_lan_addr,
 			 pf_vsi ? pf_vsi->netdev->dev_addr : zero_addr);
 	}
 
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 11/14] ice: pass mbxdata to ice_is_malicious_vf()
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
                   ` (9 preceding siblings ...)
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 10/14] ice: remove unnecessary &array[0] and just use array Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:18   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 12/14] ice: print message if ice_mbx_vf_state_handler returns an error Jacob Keller
                   ` (2 subsequent siblings)
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

The ice_is_malicious_vf() function takes information about the current
state of the mailbox during a single interrupt. This information includes
the number of messages processed so far, as well as the number of pending
messages not yet processed.

A future refactor is going to make ice_vc_process_vf_msg() call
ice_is_malicious_vf() instead of having it called separately in ice_main.c
This change will require passing all the necessary arguments into
ice_vc_process_vf_msg().

To make this simpler, have the main loop fill in the struct ice_mbx_data
and pass that rather than passing in the num_msg_proc and num_msg_pending.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_main.c  | 10 +++++++++-
 drivers/net/ethernet/intel/ice/ice_sriov.c | 14 +++-----------
 drivers/net/ethernet/intel/ice/ice_sriov.h |  5 ++---
 3 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 615a731d7afe..a7e7a186009e 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -1393,6 +1393,8 @@ static void ice_aq_cancel_waiting_tasks(struct ice_pf *pf)
 	wake_up(&pf->aq_wait_queue);
 }
 
+#define ICE_MBX_OVERFLOW_WATERMARK 64
+
 /**
  * __ice_clean_ctrlq - helper function to clean controlq rings
  * @pf: ptr to struct ice_pf
@@ -1483,6 +1485,7 @@ static int __ice_clean_ctrlq(struct ice_pf *pf, enum ice_ctl_q q_type)
 		return 0;
 
 	do {
+		struct ice_mbx_data data = {};
 		u16 opcode;
 		int ret;
 
@@ -1509,7 +1512,12 @@ static int __ice_clean_ctrlq(struct ice_pf *pf, enum ice_ctl_q q_type)
 			ice_vf_lan_overflow_event(pf, &event);
 			break;
 		case ice_mbx_opc_send_msg_to_pf:
-			if (!ice_is_malicious_vf(pf, &event, i, pending))
+			data.num_msg_proc = i;
+			data.num_pending_arq = pending;
+			data.max_num_msgs_mbx = hw->mailboxq.num_rq_entries;
+			data.async_watermark_val = ICE_MBX_OVERFLOW_WATERMARK;
+
+			if (!ice_is_malicious_vf(pf, &event, &data))
 				ice_vc_process_vf_msg(pf, &event);
 			break;
 		case ice_aqc_opc_fw_logging:
diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 938be486721e..5ae923ea979c 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -1782,16 +1782,14 @@ void ice_restore_all_vfs_msi_state(struct pci_dev *pdev)
  * ice_is_malicious_vf - helper function to detect a malicious VF
  * @pf: ptr to struct ice_pf
  * @event: pointer to the AQ event
- * @num_msg_proc: the number of messages processed so far
- * @num_msg_pending: the number of messages peinding in admin queue
+ * @mbxdata: data about the state of the mailbox
  */
 bool
 ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
-		    u16 num_msg_proc, u16 num_msg_pending)
+		    struct ice_mbx_data *mbxdata)
 {
 	s16 vf_id = le16_to_cpu(event->desc.retval);
 	struct device *dev = ice_pf_to_dev(pf);
-	struct ice_mbx_data mbxdata;
 	bool report_malvf = false;
 	struct ice_vf *vf;
 	int status;
@@ -1803,14 +1801,8 @@ ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
 	if (test_bit(ICE_VF_STATE_DIS, vf->vf_states))
 		goto out_put_vf;
 
-	mbxdata.num_msg_proc = num_msg_proc;
-	mbxdata.num_pending_arq = num_msg_pending;
-	mbxdata.max_num_msgs_mbx = pf->hw.mailboxq.num_rq_entries;
-#define ICE_MBX_OVERFLOW_WATERMARK 64
-	mbxdata.async_watermark_val = ICE_MBX_OVERFLOW_WATERMARK;
-
 	/* check to see if we have a newly malicious VF */
-	status = ice_mbx_vf_state_handler(&pf->hw, &mbxdata, &vf->mbx_info,
+	status = ice_mbx_vf_state_handler(&pf->hw, mbxdata, &vf->mbx_info,
 					  &report_malvf);
 	if (status)
 		goto out_put_vf;
diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.h b/drivers/net/ethernet/intel/ice/ice_sriov.h
index 1082b0691a3f..8fa61d954fae 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.h
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.h
@@ -36,7 +36,7 @@ void ice_free_vfs(struct ice_pf *pf);
 void ice_restore_all_vfs_msi_state(struct pci_dev *pdev);
 bool
 ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
-		    u16 num_msg_proc, u16 num_msg_pending);
+		    struct ice_mbx_data *mbxdata);
 
 int
 ice_set_vf_port_vlan(struct net_device *netdev, int vf_id, u16 vlan_id, u8 qos,
@@ -75,8 +75,7 @@ static inline void ice_restore_all_vfs_msi_state(struct pci_dev *pdev) { }
 static inline bool
 ice_is_malicious_vf(struct ice_pf __always_unused *pf,
 		    struct ice_rq_event_info __always_unused *event,
-		    u16 __always_unused num_msg_proc,
-		    u16 __always_unused num_msg_pending)
+		    struct ice_mbx_data *mbxdata)
 {
 	return false;
 }
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 12/14] ice: print message if ice_mbx_vf_state_handler returns an error
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
                   ` (10 preceding siblings ...)
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 11/14] ice: pass mbxdata to ice_is_malicious_vf() Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:18   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 13/14] ice: move ice_is_malicious_vf() to ice_virtchnl.c Jacob Keller
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 14/14] ice: call ice_is_malicious_vf() from ice_vc_process_vf_msg() Jacob Keller
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

If ice_mbx_vf_state_handler() returns an error, the ice_is_malicious_vf()
function just exits without printing anything.

Instead, use dev_warn_ratelimited to print a warning that we were unable to
check the status for this VF. The _ratelimited variant is used to avoid
potentially spamming the log if this function is failing consistently for
every single mailbox message.

Also we can drop the "goto" as it simply skips over a report_malvf check.
That variable should always be false if ice_mbx_vf_state_handler returns
non-zero.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_sriov.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 5ae923ea979c..f0daeda236de 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -1805,7 +1805,8 @@ ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
 	status = ice_mbx_vf_state_handler(&pf->hw, mbxdata, &vf->mbx_info,
 					  &report_malvf);
 	if (status)
-		goto out_put_vf;
+		dev_warn_ratelimited(dev, "Unable to check status of mailbox overflow for VF %u MAC %pM, status %d\n",
+				     vf->vf_id, vf->dev_lan_addr, status);
 
 	if (report_malvf) {
 		struct ice_vsi *pf_vsi = ice_get_main_vsi(pf);
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 13/14] ice: move ice_is_malicious_vf() to ice_virtchnl.c
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
                   ` (11 preceding siblings ...)
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 12/14] ice: print message if ice_mbx_vf_state_handler returns an error Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:19   ` Szlosek, Marek
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 14/14] ice: call ice_is_malicious_vf() from ice_vc_process_vf_msg() Jacob Keller
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

The ice_is_malicious_vf() function is currently implemented in ice_sriov.c
This function is not Single Root specific, and a future change is going to
refactor the ice_vc_process_vf_msg() function to call this instead of
calling it before ice_vc_process_vf_msg() in the main loop of
__ice_clean_ctrlq.

To make that change easier to review, first move this function into
ice_virtchnl.c but leave the call in __ice_clean_ctrlq() alone.

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_sriov.c    | 45 -------------------
 drivers/net/ethernet/intel/ice/ice_sriov.h    | 11 -----
 drivers/net/ethernet/intel/ice/ice_virtchnl.c | 45 +++++++++++++++++++
 drivers/net/ethernet/intel/ice/ice_virtchnl.h | 11 +++++
 4 files changed, 56 insertions(+), 56 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index f0daeda236de..6fa62c3cedb0 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -1777,48 +1777,3 @@ void ice_restore_all_vfs_msi_state(struct pci_dev *pdev)
 		}
 	}
 }
-
-/**
- * ice_is_malicious_vf - helper function to detect a malicious VF
- * @pf: ptr to struct ice_pf
- * @event: pointer to the AQ event
- * @mbxdata: data about the state of the mailbox
- */
-bool
-ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
-		    struct ice_mbx_data *mbxdata)
-{
-	s16 vf_id = le16_to_cpu(event->desc.retval);
-	struct device *dev = ice_pf_to_dev(pf);
-	bool report_malvf = false;
-	struct ice_vf *vf;
-	int status;
-
-	vf = ice_get_vf_by_id(pf, vf_id);
-	if (!vf)
-		return false;
-
-	if (test_bit(ICE_VF_STATE_DIS, vf->vf_states))
-		goto out_put_vf;
-
-	/* check to see if we have a newly malicious VF */
-	status = ice_mbx_vf_state_handler(&pf->hw, mbxdata, &vf->mbx_info,
-					  &report_malvf);
-	if (status)
-		dev_warn_ratelimited(dev, "Unable to check status of mailbox overflow for VF %u MAC %pM, status %d\n",
-				     vf->vf_id, vf->dev_lan_addr, status);
-
-	if (report_malvf) {
-		struct ice_vsi *pf_vsi = ice_get_main_vsi(pf);
-		u8 zero_addr[ETH_ALEN] = {};
-
-		dev_warn(dev, "VF MAC %pM on PF MAC %pM is generating asynchronous messages and may be overflowing the PF message queue. Please see the Adapter User Guide for more information\n",
-			 vf->dev_lan_addr,
-			 pf_vsi ? pf_vsi->netdev->dev_addr : zero_addr);
-	}
-
-out_put_vf:
-	ice_put_vf(vf);
-
-	return vf->mbx_info.malicious;
-}
diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.h b/drivers/net/ethernet/intel/ice/ice_sriov.h
index 8fa61d954fae..346cb2666f3a 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.h
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.h
@@ -34,9 +34,6 @@ ice_get_vf_cfg(struct net_device *netdev, int vf_id, struct ifla_vf_info *ivi);
 
 void ice_free_vfs(struct ice_pf *pf);
 void ice_restore_all_vfs_msi_state(struct pci_dev *pdev);
-bool
-ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
-		    struct ice_mbx_data *mbxdata);
 
 int
 ice_set_vf_port_vlan(struct net_device *netdev, int vf_id, u16 vlan_id, u8 qos,
@@ -72,14 +69,6 @@ static inline void ice_print_vfs_mdd_events(struct ice_pf *pf) { }
 static inline void ice_print_vf_rx_mdd_event(struct ice_vf *vf) { }
 static inline void ice_restore_all_vfs_msi_state(struct pci_dev *pdev) { }
 
-static inline bool
-ice_is_malicious_vf(struct ice_pf __always_unused *pf,
-		    struct ice_rq_event_info __always_unused *event,
-		    struct ice_mbx_data *mbxdata)
-{
-	return false;
-}
-
 static inline int
 ice_sriov_configure(struct pci_dev __always_unused *pdev,
 		    int __always_unused num_vfs)
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
index e24e3f5017ca..e0c573d9d1b9 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
@@ -3833,6 +3833,51 @@ void ice_virtchnl_set_repr_ops(struct ice_vf *vf)
 	vf->virtchnl_ops = &ice_virtchnl_repr_ops;
 }
 
+/**
+ * ice_is_malicious_vf - helper function to detect a malicious VF
+ * @pf: ptr to struct ice_pf
+ * @event: pointer to the AQ event
+ * @mbxdata: data about the state of the mailbox
+ */
+bool
+ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
+		    struct ice_mbx_data *mbxdata)
+{
+	s16 vf_id = le16_to_cpu(event->desc.retval);
+	struct device *dev = ice_pf_to_dev(pf);
+	bool report_malvf = false;
+	struct ice_vf *vf;
+	int status;
+
+	vf = ice_get_vf_by_id(pf, vf_id);
+	if (!vf)
+		return false;
+
+	if (test_bit(ICE_VF_STATE_DIS, vf->vf_states))
+		goto out_put_vf;
+
+	/* check to see if we have a newly malicious VF */
+	status = ice_mbx_vf_state_handler(&pf->hw, mbxdata, &vf->mbx_info,
+					  &report_malvf);
+	if (status)
+		dev_warn_ratelimited(dev, "Unable to check status of mailbox overflow for VF %u MAC %pM, status %d\n",
+				     vf->vf_id, vf->dev_lan_addr, status);
+
+	if (report_malvf) {
+		struct ice_vsi *pf_vsi = ice_get_main_vsi(pf);
+		u8 zero_addr[ETH_ALEN] = {};
+
+		dev_warn(dev, "VF MAC %pM on PF MAC %pM is generating asynchronous messages and may be overflowing the PF message queue. Please see the Adapter User Guide for more information\n",
+			 vf->dev_lan_addr,
+			 pf_vsi ? pf_vsi->netdev->dev_addr : zero_addr);
+	}
+
+out_put_vf:
+	ice_put_vf(vf);
+
+	return vf->mbx_info.malicious;
+}
+
 /**
  * ice_vc_process_vf_msg - Process request from VF
  * @pf: pointer to the PF structure
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.h b/drivers/net/ethernet/intel/ice/ice_virtchnl.h
index 6d5af29c855e..648a383fad85 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl.h
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.h
@@ -63,6 +63,9 @@ int
 ice_vc_send_msg_to_vf(struct ice_vf *vf, u32 v_opcode,
 		      enum virtchnl_status_code v_retval, u8 *msg, u16 msglen);
 bool ice_vc_isvalid_vsi_id(struct ice_vf *vf, u16 vsi_id);
+bool
+ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
+		    struct ice_mbx_data *mbxdata);
 void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event);
 #else /* CONFIG_PCI_IOV */
 static inline void ice_virtchnl_set_dflt_ops(struct ice_vf *vf) { }
@@ -83,6 +86,14 @@ static inline bool ice_vc_isvalid_vsi_id(struct ice_vf *vf, u16 vsi_id)
 	return false;
 }
 
+static inline bool
+ice_is_malicious_vf(struct ice_pf __always_unused *pf,
+		    struct ice_rq_event_info __always_unused *event,
+		    struct ice_mbx_data *mbxdata)
+{
+	return false;
+}
+
 static inline void
 ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
 {
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* [Intel-wired-lan] [intel-next PATCH 14/14] ice: call ice_is_malicious_vf() from ice_vc_process_vf_msg()
  2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
                   ` (12 preceding siblings ...)
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 13/14] ice: move ice_is_malicious_vf() to ice_virtchnl.c Jacob Keller
@ 2023-02-22 17:09 ` Jacob Keller
  2023-03-10 13:19   ` Szlosek, Marek
  13 siblings, 1 reply; 29+ messages in thread
From: Jacob Keller @ 2023-02-22 17:09 UTC (permalink / raw)
  To: Intel Wired LAN; +Cc: Anthony Nguyen, Jesse Brandeburg

The main loop in __ice_clean_ctrlq first checks if a VF might be malicious
before calling ice_vc_process_vf_msg(). This results in duplicate code in
both functions to obtain a reference to the VF, and exports the
ice_is_malicious_vf() from ice_virtchnl.c unnecessarily.

Refactor ice_is_malicious_vf() to be a static function that takes a pointer
to the VF. Call this in ice_vc_process_vf_msg() just after we obtain a
reference to the VF by calling ice_get_vf_by_id.

Pass the mailbox data from the __ice_clean_ctrlq function into
ice_vc_process_vf_msg() instead of calling ice_is_malicious_vf().

This reduces the number of exported functions and avoids the need to obtain
the VF reference twice for every mailbox message.

Note that the state check for ICE_VF_STATE_DIS is kept in
ice_is_malicious_vf() and we call this before checking that state in
ice_vc_process_vf_msg. This is intentional, as we stop responding to VF
messages from a VF once we detect that it may be overflowing the mailbox.
This ensures that we continue to silently ignore the message as before
without responding via ice_vc_send_msg_to_vf().

Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
---
 drivers/net/ethernet/intel/ice/ice_main.c     |  3 +-
 drivers/net/ethernet/intel/ice/ice_virtchnl.c | 36 ++++++++++---------
 drivers/net/ethernet/intel/ice/ice_virtchnl.h | 17 +++------
 3 files changed, 24 insertions(+), 32 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index a7e7a186009e..20b3f3e6eda1 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -1517,8 +1517,7 @@ static int __ice_clean_ctrlq(struct ice_pf *pf, enum ice_ctl_q q_type)
 			data.max_num_msgs_mbx = hw->mailboxq.num_rq_entries;
 			data.async_watermark_val = ICE_MBX_OVERFLOW_WATERMARK;
 
-			if (!ice_is_malicious_vf(pf, &event, &data))
-				ice_vc_process_vf_msg(pf, &event);
+			ice_vc_process_vf_msg(pf, &event, &data);
 			break;
 		case ice_aqc_opc_fw_logging:
 			ice_output_fw_log(hw, &event.desc, event.msg_buf);
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.c b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
index e0c573d9d1b9..97243c616d5d 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.c
@@ -3834,27 +3834,26 @@ void ice_virtchnl_set_repr_ops(struct ice_vf *vf)
 }
 
 /**
- * ice_is_malicious_vf - helper function to detect a malicious VF
- * @pf: ptr to struct ice_pf
- * @event: pointer to the AQ event
+ * ice_is_malicious_vf - check if this vf might be overflowing mailbox
+ * @vf: the VF to check
  * @mbxdata: data about the state of the mailbox
+ *
+ * Detect if a given VF might be malicious and attempting to overflow the PF
+ * mailbox. If so, log a warning message and ignore this event.
  */
-bool
-ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
-		    struct ice_mbx_data *mbxdata)
+static bool
+ice_is_malicious_vf(struct ice_vf *vf, struct ice_mbx_data *mbxdata)
 {
-	s16 vf_id = le16_to_cpu(event->desc.retval);
-	struct device *dev = ice_pf_to_dev(pf);
 	bool report_malvf = false;
-	struct ice_vf *vf;
+	struct device *dev;
+	struct ice_pf *pf;
 	int status;
 
-	vf = ice_get_vf_by_id(pf, vf_id);
-	if (!vf)
-		return false;
+	pf = vf->pf;
+	dev = ice_pf_to_dev(pf);
 
 	if (test_bit(ICE_VF_STATE_DIS, vf->vf_states))
-		goto out_put_vf;
+		return vf->mbx_info.malicious;
 
 	/* check to see if we have a newly malicious VF */
 	status = ice_mbx_vf_state_handler(&pf->hw, mbxdata, &vf->mbx_info,
@@ -3872,9 +3871,6 @@ ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
 			 pf_vsi ? pf_vsi->netdev->dev_addr : zero_addr);
 	}
 
-out_put_vf:
-	ice_put_vf(vf);
-
 	return vf->mbx_info.malicious;
 }
 
@@ -3882,11 +3878,13 @@ ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
  * ice_vc_process_vf_msg - Process request from VF
  * @pf: pointer to the PF structure
  * @event: pointer to the AQ event
+ * @mbxdata: information used to detect VF attempting mailbox overflow
  *
  * called from the common asq/arq handler to
  * process request from VF
  */
-void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
+void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event,
+			   struct ice_mbx_data *mbxdata)
 {
 	u32 v_opcode = le32_to_cpu(event->desc.cookie_high);
 	s16 vf_id = le16_to_cpu(event->desc.retval);
@@ -3908,6 +3906,10 @@ void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
 
 	mutex_lock(&vf->cfg_lock);
 
+	/* Check if the VF is trying to overflow the mailbox */
+	if (ice_is_malicious_vf(vf, mbxdata))
+		goto finish;
+
 	/* Check if VF is disabled. */
 	if (test_bit(ICE_VF_STATE_DIS, vf->vf_states)) {
 		err = -EPERM;
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl.h b/drivers/net/ethernet/intel/ice/ice_virtchnl.h
index 648a383fad85..cd747718de73 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl.h
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl.h
@@ -63,10 +63,8 @@ int
 ice_vc_send_msg_to_vf(struct ice_vf *vf, u32 v_opcode,
 		      enum virtchnl_status_code v_retval, u8 *msg, u16 msglen);
 bool ice_vc_isvalid_vsi_id(struct ice_vf *vf, u16 vsi_id);
-bool
-ice_is_malicious_vf(struct ice_pf *pf, struct ice_rq_event_info *event,
-		    struct ice_mbx_data *mbxdata);
-void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event);
+void ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event,
+			   struct ice_mbx_data *mbxdata);
 #else /* CONFIG_PCI_IOV */
 static inline void ice_virtchnl_set_dflt_ops(struct ice_vf *vf) { }
 static inline void ice_virtchnl_set_repr_ops(struct ice_vf *vf) { }
@@ -86,16 +84,9 @@ static inline bool ice_vc_isvalid_vsi_id(struct ice_vf *vf, u16 vsi_id)
 	return false;
 }
 
-static inline bool
-ice_is_malicious_vf(struct ice_pf __always_unused *pf,
-		    struct ice_rq_event_info __always_unused *event,
-		    struct ice_mbx_data *mbxdata)
-{
-	return false;
-}
-
 static inline void
-ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event)
+ice_vc_process_vf_msg(struct ice_pf *pf, struct ice_rq_event_info *event,
+		      struct ice_mbx_data *mbxdata)
 {
 }
 #endif /* !CONFIG_PCI_IOV */
-- 
2.39.1.405.gd4c25cc71f83

_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 01/14] ice: re-order ice_mbx_reset_snapshot function
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 01/14] ice: re-order ice_mbx_reset_snapshot function Jacob Keller
@ 2023-03-10 13:15   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:15 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 01/14] ice: re-order
> ice_mbx_reset_snapshot function
> 
> A future change is going to refactor the VF mailbox overflow detection logic,
> including modifying ice_mbx_reset_snapshot and its callers. To make this
> change easier to review, first move the ice_mbx_reset_snapshot function
> higher in the ice_vf_mbx.c file.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 48 ++++++++++-----------
>  1 file changed, 24 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
> b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
> index f56fa94ff3d0..2fe9a9504914 100644
> --- a/drivers/net/ethernet/intel/ice/ice_vf_mbx.c
> +++ b/drivers/net/ethernet/intel/ice/ice_vf_mbx.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 02/14] ice: convert ice_mbx_clear_malvf to void and use WARN
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 02/14] ice: convert ice_mbx_clear_malvf to void and use WARN Jacob Keller
@ 2023-03-10 13:15   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:15 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 02/14] ice: convert
> ice_mbx_clear_malvf to void and use WARN
> 
> The ice_mbx_clear_malvf function checks for a few error conditions before
> clearing the appropriate data. These error conditions are really warnings that
> should never occur in a properly initialized driver. Every caller of
> ice_mbx_clear_malvf just prints a dev_dbg message on failure which will
> generally be ignored.
> 
> Convert this function to void and switch the error return values to
> WARN_ON. This will make any potentially misconfiguration more visible and
> makes future refactors that involve changing how we store the malicious VF
> data easier.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_sriov.c  |  6 ++----
> drivers/net/ethernet/intel/ice/ice_vf_lib.c | 12 ++++--------
> drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 16 +++++++---------
> drivers/net/ethernet/intel/ice/ice_vf_mbx.h |  2 +-
>  4 files changed, 14 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index 96a64c25e2ef..7107c279752a 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 03/14] ice: track malicious VFs in new ice_mbx_vf_info structure
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 03/14] ice: track malicious VFs in new ice_mbx_vf_info structure Jacob Keller
@ 2023-03-10 13:15   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:15 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 03/14] ice: track malicious VFs in
> new ice_mbx_vf_info structure
> 
> Currently the PF tracks malicious VFs in a malvfs bitmap which is used by the
> ice_mbx_clear_malvf and ice_mbx_report_malvf functions. This bitmap is
> used to ensure that we only report a VF as malicious once rather than
> continuously spamming the event log.
> 
> This mechanism of storage for the malicious indication works well enough for
> SR-IOV. However, it will not work with Scalable IOV. This is because Scalable
> IOV VFs can be allocated dynamically and might change VF ID when their
> underlying VSI changes.
> 
> To support this, the mailbox overflow logic will need to be refactored.
> First, introduce a new ice_mbx_vf_info structure which will be used to store
> data about a VF. Embed this structure in the struct ice_vf, and ensure it gets
> initialized when a new VF is created.
> 
> For now this only stores the malicious indicator bit. Pass a pointer to the VF's
> mbx_info structure instead of using a bitmap to keep track of these bits.
> 
> A future change will extend this structure and the rest of the logic associated
> with the overflow detection.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_sriov.c  |  7 +-
>  drivers/net/ethernet/intel/ice/ice_type.h   |  7 ++
>  drivers/net/ethernet/intel/ice/ice_vf_lib.c | 10 +--
> drivers/net/ethernet/intel/ice/ice_vf_lib.h |  2 +-
> drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 71 +++++++++------------
> drivers/net/ethernet/intel/ice/ice_vf_mbx.h |  9 +--
>  6 files changed, 53 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index 7107c279752a..44b94276df91 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 04/14] ice: move VF overflow message count into struct ice_mbx_vf_info
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 04/14] ice: move VF overflow message count into struct ice_mbx_vf_info Jacob Keller
@ 2023-03-10 13:16   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:16 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 04/14] ice: move VF overflow
> message count into struct ice_mbx_vf_info
> 
> The ice driver has some logic in ice_vf_mbx.c used to detect potentially
> malicious VF behavior with regards to overflowing the PF mailbox. This logic
> currently stores message counts in struct ice_mbx_vf_counter.vf_cntr as an
> array. This array is allocated during initialization with ice_mbx_init_snapshot.
> 
> This logic makes sense for SR-IOV where all VFs are allocated at once up
> front. However, in the future with Scalable IOV this logic will not work.
> VFs can be added and removed dynamically. We could try to keep the vf_cntr
> array for the maximum possible number of VFs, but this is a waste of
> memory.
> 
> Use the recently introduced struct ice_mbx_vf_info structure to store the
> message count. Pass a pointer to the mbx_info for a VF instead of using its VF
> ID. Replace the array of VF message counts with a linked list that tracks all
> currently active mailbox tracking info structures.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_sriov.c  |   9 +-
>  drivers/net/ethernet/intel/ice/ice_type.h   |  18 +--
>  drivers/net/ethernet/intel/ice/ice_vf_lib.c |   7 +-
>  drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 167 +++++++-------------
>  drivers/net/ethernet/intel/ice/ice_vf_mbx.h |   8 +-
>  5 files changed, 69 insertions(+), 140 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index 44b94276df91..8820f269bfdf 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 05/14] ice: remove ice_mbx_deinit_snapshot
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 05/14] ice: remove ice_mbx_deinit_snapshot Jacob Keller
@ 2023-03-10 13:16   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:16 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 05/14] ice: remove
> ice_mbx_deinit_snapshot
> 
> The ice_mbx_deinit_snapshot function's only remaining job is to clear the
> previous snapshot data. This snapshot data is initialized when SR-IOV adds
> VFs, so it is not necessary to clear this data when removing VFs. Since no
> allocation occurs we no longer need to free anything and we can safely
> remove this function.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_sriov.c  |  5 +----
> drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 14 --------------
> drivers/net/ethernet/intel/ice/ice_vf_mbx.h |  1 -
>  3 files changed, 1 insertion(+), 19 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index 8820f269bfdf..b65025b51526 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 06/14] ice: merge ice_mbx_report_malvf with ice_mbx_vf_state_handler
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 06/14] ice: merge ice_mbx_report_malvf with ice_mbx_vf_state_handler Jacob Keller
@ 2023-03-10 13:17   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:17 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 06/14] ice: merge
> ice_mbx_report_malvf with ice_mbx_vf_state_handler
> 
> The ice_mbx_report_malvf function is used to update the
> ice_mbx_vf_info.malicious member after we detect a malicious VF. This is
> done by calling ice_mbx_report_malvf after ice_mbx_vf_state_handler sets
> its "is_malvf" return parameter true.
> 
> Instead of requiring two steps, directly update the malicious bit in the state
> handler, and remove the need for separately calling ice_mbx_report_malvf.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_sriov.c  | 34 +++++---------
> drivers/net/ethernet/intel/ice/ice_vf_mbx.c | 51 ++++++---------------
> drivers/net/ethernet/intel/ice/ice_vf_mbx.h |  5 +-
>  3 files changed, 28 insertions(+), 62 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index b65025b51526..71ce3998dd75 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 07/14] ice: initialize mailbox snapshot earlier in PF init
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 07/14] ice: initialize mailbox snapshot earlier in PF init Jacob Keller
@ 2023-03-10 13:17   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:17 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 07/14] ice: initialize mailbox
> snapshot earlier in PF init
> 
> Now that we no longer depend on the number of VFs being allocated, we can
> move the ice_mbx_init_snapshot function earlier. This will be required by
> Scalable IOV as we will not be calling ice_sriov_configure for Scalable VFs.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_main.c   | 1 +
>  drivers/net/ethernet/intel/ice/ice_sriov.c  | 2 --
> drivers/net/ethernet/intel/ice/ice_vf_mbx.h | 4 ++++
>  3 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c
> b/drivers/net/ethernet/intel/ice/ice_main.c
> index 567694bf098b..615a731d7afe 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 08/14] ice: declare ice_vc_process_vf_msg in ice_virtchnl.h
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 08/14] ice: declare ice_vc_process_vf_msg in ice_virtchnl.h Jacob Keller
@ 2023-03-10 13:17   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:17 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 08/14] ice: declare
> ice_vc_process_vf_msg in ice_virtchnl.h
> 
> The ice_vc_process_vf_msg function is the main entry point for handling
> virtchnl messages. This function is defined in ice_virtchnl.c but its declaration
> is still in ice_sriov.c
> 
> The ice_sriov.c file used to contain all of the virtualization logic until commit
> bf93bf791cec ("ice: introduce ice_virtchnl.c and ice_virtchnl.h") moved the
> virtchnl logic to its own file.
> 
> The ice_vc_process_vf_msg function should have had its declaration moved
> to ice_virtchnl.h then. Fix this.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_sriov.h    | 3 ---
>  drivers/net/ethernet/intel/ice/ice_virtchnl.h | 6 ++++++
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.h
> b/drivers/net/ethernet/intel/ice/ice_sriov.h
> index 955ab810a198..1082b0691a3f 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.h
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.h

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 09/14] ice: always report VF overflowing mailbox even without PF VSI
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 09/14] ice: always report VF overflowing mailbox even without PF VSI Jacob Keller
@ 2023-03-10 13:17   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:17 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 09/14] ice: always report VF
> overflowing mailbox even without PF VSI
> 
> In ice_is_malicious_vf we report a message warning the system
> administrator when a VF is potentially spamming the PF with asynchronous
> messages that could overflow the PF mailbox.
> 
> The specific message was requested by our customer support team to
> include the VF and PF MAC address. In some cases we may not be able to
> locate the PF VSI to obtain the MAC address for the PF. The current
> implementation discards the message entirely in this case. Fix this to instead
> print a zero address in that case so that we always print something here.
> Note that dev_warn will also include the PCI device information allowing
> another mechanism for determining on which PF the potentially malicious VF
> belongs.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_sriov.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index 6764e677a345..185673afb781 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 10/14] ice: remove unnecessary &array[0] and just use array
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 10/14] ice: remove unnecessary &array[0] and just use array Jacob Keller
@ 2023-03-10 13:18   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:18 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 10/14] ice: remove unnecessary
> &array[0] and just use array
> 
> In ice_is_malicious_vf we print the VF MAC address using %pM by passing
> the address of the first element of vf->dev_lan_addr. This is equivalent to
> just passing vf->dev_lan_addr, so do that.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_sriov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index 185673afb781..938be486721e 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 11/14] ice: pass mbxdata to ice_is_malicious_vf()
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 11/14] ice: pass mbxdata to ice_is_malicious_vf() Jacob Keller
@ 2023-03-10 13:18   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:18 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 11/14] ice: pass mbxdata to
> ice_is_malicious_vf()
> 
> The ice_is_malicious_vf() function takes information about the current state
> of the mailbox during a single interrupt. This information includes the
> number of messages processed so far, as well as the number of pending
> messages not yet processed.
> 
> A future refactor is going to make ice_vc_process_vf_msg() call
> ice_is_malicious_vf() instead of having it called separately in ice_main.c This
> change will require passing all the necessary arguments into
> ice_vc_process_vf_msg().
> 
> To make this simpler, have the main loop fill in the struct ice_mbx_data and
> pass that rather than passing in the num_msg_proc and num_msg_pending.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_main.c  | 10 +++++++++-
> drivers/net/ethernet/intel/ice/ice_sriov.c | 14 +++-----------
> drivers/net/ethernet/intel/ice/ice_sriov.h |  5 ++---
>  3 files changed, 14 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c
> b/drivers/net/ethernet/intel/ice/ice_main.c
> index 615a731d7afe..a7e7a186009e 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 12/14] ice: print message if ice_mbx_vf_state_handler returns an error
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 12/14] ice: print message if ice_mbx_vf_state_handler returns an error Jacob Keller
@ 2023-03-10 13:18   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:18 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 12/14] ice: print message if
> ice_mbx_vf_state_handler returns an error
> 
> If ice_mbx_vf_state_handler() returns an error, the ice_is_malicious_vf()
> function just exits without printing anything.
> 
> Instead, use dev_warn_ratelimited to print a warning that we were unable to
> check the status for this VF. The _ratelimited variant is used to avoid
> potentially spamming the log if this function is failing consistently for every
> single mailbox message.
> 
> Also we can drop the "goto" as it simply skips over a report_malvf check.
> That variable should always be false if ice_mbx_vf_state_handler returns
> non-zero.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_sriov.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index 5ae923ea979c..f0daeda236de 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 13/14] ice: move ice_is_malicious_vf() to ice_virtchnl.c
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 13/14] ice: move ice_is_malicious_vf() to ice_virtchnl.c Jacob Keller
@ 2023-03-10 13:19   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:19 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 13/14] ice: move
> ice_is_malicious_vf() to ice_virtchnl.c
> 
> The ice_is_malicious_vf() function is currently implemented in ice_sriov.c
> This function is not Single Root specific, and a future change is going to
> refactor the ice_vc_process_vf_msg() function to call this instead of calling it
> before ice_vc_process_vf_msg() in the main loop of __ice_clean_ctrlq.
> 
> To make that change easier to review, first move this function into
> ice_virtchnl.c but leave the call in __ice_clean_ctrlq() alone.
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_sriov.c    | 45 -------------------
>  drivers/net/ethernet/intel/ice/ice_sriov.h    | 11 -----
>  drivers/net/ethernet/intel/ice/ice_virtchnl.c | 45 +++++++++++++++++++
> drivers/net/ethernet/intel/ice/ice_virtchnl.h | 11 +++++
>  4 files changed, 56 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index f0daeda236de..6fa62c3cedb0 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

* Re: [Intel-wired-lan] [intel-next PATCH 14/14] ice: call ice_is_malicious_vf() from ice_vc_process_vf_msg()
  2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 14/14] ice: call ice_is_malicious_vf() from ice_vc_process_vf_msg() Jacob Keller
@ 2023-03-10 13:19   ` Szlosek, Marek
  0 siblings, 0 replies; 29+ messages in thread
From: Szlosek, Marek @ 2023-03-10 13:19 UTC (permalink / raw)
  To: Intel Wired LAN



> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jacob Keller
> Sent: środa, 22 lutego 2023 18:09
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>
> Subject: [Intel-wired-lan] [intel-next PATCH 14/14] ice: call
> ice_is_malicious_vf() from ice_vc_process_vf_msg()
> 
> The main loop in __ice_clean_ctrlq first checks if a VF might be malicious
> before calling ice_vc_process_vf_msg(). This results in duplicate code in both
> functions to obtain a reference to the VF, and exports the
> ice_is_malicious_vf() from ice_virtchnl.c unnecessarily.
> 
> Refactor ice_is_malicious_vf() to be a static function that takes a pointer to
> the VF. Call this in ice_vc_process_vf_msg() just after we obtain a reference
> to the VF by calling ice_get_vf_by_id.
> 
> Pass the mailbox data from the __ice_clean_ctrlq function into
> ice_vc_process_vf_msg() instead of calling ice_is_malicious_vf().
> 
> This reduces the number of exported functions and avoids the need to
> obtain the VF reference twice for every mailbox message.
> 
> Note that the state check for ICE_VF_STATE_DIS is kept in
> ice_is_malicious_vf() and we call this before checking that state in
> ice_vc_process_vf_msg. This is intentional, as we stop responding to VF
> messages from a VF once we detect that it may be overflowing the mailbox.
> This ensures that we continue to silently ignore the message as before
> without responding via ice_vc_send_msg_to_vf().
> 
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> ---
>  drivers/net/ethernet/intel/ice/ice_main.c     |  3 +-
>  drivers/net/ethernet/intel/ice/ice_virtchnl.c | 36 ++++++++++---------
> drivers/net/ethernet/intel/ice/ice_virtchnl.h | 17 +++------
>  3 files changed, 24 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c
> b/drivers/net/ethernet/intel/ice/ice_main.c
> index a7e7a186009e..20b3f3e6eda1 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c

Tested-by: Marek Szlosek <marek.szlosek@intel.com>
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

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

end of thread, other threads:[~2023-03-10 13:19 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-22 17:09 [Intel-wired-lan] [intel-next PATCH 00/14] ice: refactor mailbox overflow detection Jacob Keller
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 01/14] ice: re-order ice_mbx_reset_snapshot function Jacob Keller
2023-03-10 13:15   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 02/14] ice: convert ice_mbx_clear_malvf to void and use WARN Jacob Keller
2023-03-10 13:15   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 03/14] ice: track malicious VFs in new ice_mbx_vf_info structure Jacob Keller
2023-03-10 13:15   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 04/14] ice: move VF overflow message count into struct ice_mbx_vf_info Jacob Keller
2023-03-10 13:16   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 05/14] ice: remove ice_mbx_deinit_snapshot Jacob Keller
2023-03-10 13:16   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 06/14] ice: merge ice_mbx_report_malvf with ice_mbx_vf_state_handler Jacob Keller
2023-03-10 13:17   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 07/14] ice: initialize mailbox snapshot earlier in PF init Jacob Keller
2023-03-10 13:17   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 08/14] ice: declare ice_vc_process_vf_msg in ice_virtchnl.h Jacob Keller
2023-03-10 13:17   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 09/14] ice: always report VF overflowing mailbox even without PF VSI Jacob Keller
2023-03-10 13:17   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 10/14] ice: remove unnecessary &array[0] and just use array Jacob Keller
2023-03-10 13:18   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 11/14] ice: pass mbxdata to ice_is_malicious_vf() Jacob Keller
2023-03-10 13:18   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 12/14] ice: print message if ice_mbx_vf_state_handler returns an error Jacob Keller
2023-03-10 13:18   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 13/14] ice: move ice_is_malicious_vf() to ice_virtchnl.c Jacob Keller
2023-03-10 13:19   ` Szlosek, Marek
2023-02-22 17:09 ` [Intel-wired-lan] [intel-next PATCH 14/14] ice: call ice_is_malicious_vf() from ice_vc_process_vf_msg() Jacob Keller
2023-03-10 13:19   ` Szlosek, Marek

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