When the i40e driver receives VF reset requests from multiple sources, some requests may not be handled. For example, a VFLR interrupt might be ignored if it occurs while a VF is already resetting as part of an `ndo` request. In such scenarios, the VFLR is lost and, depending on timing, the VF may be left uninitialized. This can cause the VF driver to become stuck in an initialization loop until another VF reset is triggered.
Currently, in i40e_vc_reset_vf, the driver attempts to reset the VF up to 20 times, logging an error if all attempts fail. This logic assumes that i40e_reset_vf returns false when another reset is already in progress. However, i40e_reset_vf currently always returns true, which causes overlapping resets to be silently ignored. The first patch updates i40e_reset_vf to return false if a reset is already in progress. This aligns with the retry logic used in i40e_vc_reset_vf. While the first patch addresses resets triggered via ndo operations, VFLR interrupts can also initiate VF resets. In that case, the driver directly calls i40e_reset_vf, and if the reset is skipped due to another one being in progress, the VF reest is not retried. The second patch addresses this by re-setting the I40E_VFLR_EVENT_PENDING bit, ensuring the VFLR is handled during the next service task execution. --- Changes in v2: - Patch 1: modified doc string for i40e_reset_vf function - Patch 2: removed unnecessary doc string changes from the patch Robert Malz (2): i40e: return false from i40e_reset_vf if reset is in progress i40e: retry VFLR handling if there is ongoing VF reset drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) -- 2.34.1
