From: Alice Michael <alice.michael@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [next PATCH S78-V8 04/12] i40e: don't hold spinlock while resetting VF
Date: Tue, 22 Aug 2017 06:57:46 -0400 [thread overview]
Message-ID: <20170822105754.29486-5-alice.michael@intel.com> (raw)
In-Reply-To: <20170822105754.29486-1-alice.michael@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
When we refactored handling of the PVID in commit 9af52f60b2d9
("i40e: use (add|rm)_vlan_all_mac helper functions when changing PVID")
we introduced a scheduling while atomic regression.
This occurred because we now held the spinlock across a call to
i40e_reset_vf(), which results in a usleep_range() call that triggers
a scheduling while atomic bug. This was rare as it only occurred if the
user configured a VLAN on a VF and also attempted to reconfigure the VF
from the host system with a port VLAN.
We do need to hold the lock while calling i40e_is_vsi_in_vlan(), but we
should not be holding it while we reset the VF.
We'll fix this by introducing a separate helper function
i40e_vsi_has_vlans which checks whether we have a PVID and whether the
VSI has configured VLANs. This helper function will manage its own need
for the mac_filter_hash_lock.
Then, we can move the acquiring of the spinlock until after we reset the
VF, which ensures that we do not sleep while holding the lock.
Using a separate function like this makes the code more clear and is
easier to read than attempting to release and re-acquire the spinlock
when we reset the VF.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 36 +++++++++++++++++++---
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index e156096..25628f5 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -2923,6 +2923,34 @@ int i40e_ndo_set_vf_mac(struct net_device *netdev, int vf_id, u8 *mac)
}
/**
+ * i40e_vsi_has_vlans - True if VSI has configured VLANs
+ * @vsi: pointer to the vsi
+ *
+ * Check if a VSI has configured any VLANs. False if we have a port VLAN or if
+ * we have no configured VLANs. Do not call while holding the
+ * mac_filter_hash_lock.
+ */
+static bool i40e_vsi_has_vlans(struct i40e_vsi *vsi)
+{
+ bool have_vlans;
+
+ /* If we have a port VLAN, then the VSI cannot have any VLANs
+ * configured, as all MAC/VLAN filters will be assigned to the PVID.
+ */
+ if (vsi->info.pvid)
+ return false;
+
+ /* Since we don't have a PVID, we know that if the device is in VLAN
+ * mode it must be because of a VLAN filter configured on this VSI.
+ */
+ spin_lock_bh(&vsi->mac_filter_hash_lock);
+ have_vlans = i40e_is_vsi_in_vlan(vsi);
+ spin_unlock_bh(&vsi->mac_filter_hash_lock);
+
+ return have_vlans;
+}
+
+/**
* i40e_ndo_set_vf_port_vlan
* @netdev: network interface device structure
* @vf_id: VF identifier
@@ -2974,10 +3002,7 @@ int i40e_ndo_set_vf_port_vlan(struct net_device *netdev, int vf_id,
/* duplicate request, so just return success */
goto error_pvid;
- /* Locked once because multiple functions below iterate list */
- spin_lock_bh(&vsi->mac_filter_hash_lock);
-
- if (le16_to_cpu(vsi->info.pvid) == 0 && i40e_is_vsi_in_vlan(vsi)) {
+ if (i40e_vsi_has_vlans(vsi)) {
dev_err(&pf->pdev->dev,
"VF %d has already configured VLAN filters and the administrator is requesting a port VLAN override.\nPlease unload and reload the VF driver for this change to take effect.\n",
vf_id);
@@ -2990,6 +3015,9 @@ int i40e_ndo_set_vf_port_vlan(struct net_device *netdev, int vf_id,
vsi = pf->vsi[vf->lan_vsi_idx];
}
+ /* Locked once because multiple functions below iterate list */
+ spin_lock_bh(&vsi->mac_filter_hash_lock);
+
/* Check for condition where there was already a port VLAN ID
* filter set and now it is being deleted by setting it to zero.
* Additionally check for the condition where there was a port
--
2.9.4
next prev parent reply other threads:[~2017-08-22 10:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-22 10:57 [Intel-wired-lan] [next PATCH S78-V8 00/12] Change Log Alice Michael
2017-08-22 10:57 ` [Intel-wired-lan] [next PATCH S78-V8 01/12] i40e: Fix reporting of supported link modes Alice Michael
2017-08-23 16:28 ` Bowers, AndrewX
2017-08-22 10:57 ` [Intel-wired-lan] [next PATCH S78-V8 02/12] i40e: Add support for 'ethtool -m' Alice Michael
2017-08-23 16:29 ` Bowers, AndrewX
2017-08-22 10:57 ` [Intel-wired-lan] [next PATCH S78-V8 03/12] i40e: use admin queue for setting LEDs behavior Alice Michael
2017-08-23 16:29 ` Bowers, AndrewX
2017-08-22 10:57 ` Alice Michael [this message]
2017-08-23 16:42 ` [Intel-wired-lan] [next PATCH S78-V8 04/12] i40e: don't hold spinlock while resetting VF Bowers, AndrewX
2017-08-22 10:57 ` [Intel-wired-lan] [next PATCH S78-V8 05/12] i40e: drop i40e_pf *pf from i40e_vc_disable_vf() Alice Michael
2017-08-23 16:43 ` Bowers, AndrewX
2017-08-22 10:57 ` [Intel-wired-lan] [next PATCH S78-V8 06/12] i40e: make use of i40e_vc_disable_vf Alice Michael
2017-08-23 20:41 ` Bowers, AndrewX
2017-08-22 10:57 ` [Intel-wired-lan] [next PATCH S78-V8 07/12] i40e: ensure reset occurs when disabling VF Alice Michael
2017-08-23 20:42 ` Bowers, AndrewX
2017-08-22 10:57 ` [Intel-wired-lan] [next PATCH S78-V8 08/12] i40evf: Enable VF to request an alternate queue allocation Alice Michael
2017-08-23 20:43 ` Bowers, AndrewX
2017-08-22 10:57 ` [Intel-wired-lan] [next PATCH S78-V8 09/12] i40e: make i40evf_map_rings_to_vectors void Alice Michael
2017-08-23 20:52 ` Bowers, AndrewX
2017-08-22 10:57 ` [Intel-wired-lan] [next PATCH S78-V8 10/12] i40e: fix handling of vf_states variable Alice Michael
2017-08-23 20:53 ` Bowers, AndrewX
2017-08-22 10:57 ` [Intel-wired-lan] [next PATCH S78-V8 11/12] i40e: fix client notify of VF reset Alice Michael
2017-08-23 20:53 ` Bowers, AndrewX
2017-08-22 10:57 ` [Intel-wired-lan] [next PATCH S78-V8 12/12] i40e: Stop dropping 802.1ad tags (eth proto 0x88a8 Alice Michael
2017-08-23 20:54 ` Bowers, AndrewX
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=20170822105754.29486-5-alice.michael@intel.com \
--to=alice.michael@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