]> git.baikalelectronics.ru Git - kernel.git/commit
i40e: don't hold spinlock while resetting VF
authorJacob Keller <jacob.e.keller@intel.com>
Tue, 22 Aug 2017 10:57:46 +0000 (06:57 -0400)
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>
Mon, 2 Oct 2017 19:46:35 +0000 (12:46 -0700)
commit0d0ad7185a32b0dd1d16f88733e43b2babcb9a13
tree54c828e2324d44386b545f7d1cb3f4ef275c3a14
parentb25f195da61ed4a91574bc4d29a40007783e38c0
i40e: don't hold spinlock while resetting VF

When we refactored handling of the PVID in commit 447af199f624
("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>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c