On Mon, Mar 16, 2026 at 11:42:05AM +0100, Petr Oros wrote: > The iavf VLAN filter state machine has several design issues that lead > to race conditions between userspace add/del calls and the watchdog > task's virtchnl processing. Filters can get lost or leak HW resources, > especially during interface down/up cycles and namespace moves. > > The root problems: > > 1) On interface down, all VLAN filters are sent as DEL to PF and > re-added on interface up. This is unnecessary and creates multiple > race windows (details below). > > 2) The DELETE path immediately frees the filter struct after sending > the DEL message, without waiting for PF confirmation. If the PF > rejects the DEL, the filter remains in HW but the driver lost its > tracking structure. Race conditions between a pending DEL and > add/reset operations cannot be resolved because the struct is gone. > > 3) VIRTCHNL_OP_ADD_VLAN (V1) had no success completion handler, so > filters stayed in IS_NEW state permanently.
... > This series addresses all three issues: > > Patch 1 renames IS_NEW to ADDING for clarity. > > Patch 2 removes the DISABLE/INACTIVE state machinery so VLAN filters > stay ACTIVE across down/up cycles. This is the core behavioral > change -- VLAN filters are no longer sent as DEL to PF on interface > down, and iavf_restore_filters() is removed since there is nothing > to restore. > > Patch 3 adds a REMOVING state to make the DELETE path symmetric with > ADD -- filters are only freed after PF confirms the deletion. If the > PF rejects the DEL, the filter reverts to ACTIVE instead of being > lost. > > Patch 4 hardens the remaining race windows: adds V1 ADD success > handler and prevents redundant DEL on filters already in REMOVING > state. For the series: Reviewed-by: Simon Horman <[email protected]>
