diff options
| author | Jacob Keller <[email protected]> | 2017-08-22 06:57:46 -0400 |
|---|---|---|
| committer | Jeff Kirsher <[email protected]> | 2017-10-02 12:46:35 -0700 |
| commit | ba4e003d29c1d32776f156695fb00adf7df86ee2 (patch) | |
| tree | 54c828e2324d44386b545f7d1cb3f4ef275c3a14 /tools/perf/scripts/python/export-to-sqlite.py | |
| parent | 00f6c2f5e20bbdb638e58c50c6e6b1d8b796d6f6 (diff) | |
i40e: don't hold spinlock while resetting VF
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 <[email protected]>
Tested-by: Andrew Bowers <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/export-to-sqlite.py')
0 files changed, 0 insertions, 0 deletions