From: Jacob Keller <jacob.e.keller@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [net-next PATCH 04/11] ice: move clear_malvf call in ice_free_vfs
Date: Tue, 15 Feb 2022 17:31:20 -0800 [thread overview]
Message-ID: <20220216013127.3263153-5-jacob.e.keller@intel.com> (raw)
In-Reply-To: <20220216013127.3263153-1-jacob.e.keller@intel.com>
The ice_mbx_clear_malvf function is used to clear the indication and
count of how many times a VF was detected as malicious. During
ice_free_vfs, we use this function to ensure that all removed VFs are
reset to a clean state.
The call currently is done at the end of ice_free_vfs() using a tmp
value to iterate over all of the entries in the bitmap.
This separate iteration using tmp is problematic for a planned refactor
of the VF array data structure. To avoid this, lets move the call
slightly higher into the function inside the loop where we teardown all
of the VFs. This avoids one use of the tmp value used for iteration.
We'll fix the other user in a future change.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
index 44037d569755..c469b32f665b 100644
--- a/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c
@@ -536,6 +536,12 @@ void ice_free_vfs(struct ice_pf *pf)
ice_free_vf_res(vf);
}
+ /* clear malicious info since the VF is getting released */
+ if (ice_mbx_clear_malvf(&hw->mbx_snapshot, pf->malvfs,
+ ICE_MAX_VF_COUNT, vf->vf_id))
+ dev_dbg(dev, "failed to clear malicious VF state for VF %u\n",
+ vf->vf_id);
+
mutex_unlock(&vf->cfg_lock);
mutex_destroy(&vf->cfg_lock);
@@ -566,13 +572,6 @@ void ice_free_vfs(struct ice_pf *pf)
}
}
- /* clear malicious info if the VFs are getting released */
- for (i = 0; i < tmp; i++)
- if (ice_mbx_clear_malvf(&hw->mbx_snapshot, pf->malvfs,
- ICE_MAX_VF_COUNT, i))
- dev_dbg(dev, "failed to clear malicious VF state for VF %u\n",
- i);
-
clear_bit(ICE_VF_DIS, pf->state);
clear_bit(ICE_FLAG_SRIOV_ENA, pf->flags);
}
--
2.35.1.129.gb80121027d12
next prev parent reply other threads:[~2022-02-16 1:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-16 1:31 [Intel-wired-lan] [net-next PATCH 00/11] ice: convert VF storage to hash table Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 01/11] ice: refactor unwind cleanup in eswitch mode Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 02/11] ice: store VF pointer instead of VF ID Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 03/11] ice: pass num_vfs to ice_set_per_vf_res() Jacob Keller
2022-02-16 1:31 ` Jacob Keller [this message]
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 05/11] ice: move VFLR acknowledge during ice_free_vfs Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 06/11] ice: remove checks in ice_vc_send_msg_to_vf Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 07/11] ice: use ice_for_each_vf for iteration during removal Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 08/11] ice: convert ice_for_each_vf to include VF entry iterator Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 09/11] ice: factor VF variables to separate structure Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 10/11] ice: introduce VF accessor functions Jacob Keller
2022-02-16 1:31 ` [Intel-wired-lan] [net-next PATCH 11/11] ice: convert VF storage to hash table with krefs and RCU Jacob Keller
2022-02-16 1:43 ` Keller, Jacob E
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220216013127.3263153-5-jacob.e.keller@intel.com \
--to=jacob.e.keller@intel.com \
--cc=intel-wired-lan@osuosl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox