[PATCH iwl-net v2 0/4] iavf: fix VLAN filter state machine races

Petr Oros
2026-04-17T14:29:59Z

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.

Why removing VLAN filters on down/up is unnecessary:

Unlike MAC filters, which need to be re-evaluated on up because the
PF can administratively change the MAC address during down, VLAN
filters are purely user-controlled. The PF cannot change them while
the VF is down. When the VF goes down, VIRTCHNL_OP_DISABLE_QUEUES
stops all traffic; VLAN filters sitting in PF HW are harmless
because no packets flow through the disabled queues.

Compare with other filter types in iavf_down():
- MAC filters: only the current MAC is removed (it gets re-read from
PF on up in case it was administratively changed)
- Cloud filters: left as-is across down/up
- FDIR filters: left as-is across down/up

VLAN filters were the only type going through a full DEL+ADD cycle,
and this caused real problems:

- With spoofcheck enabled, the PF activates TX VLAN anti-spoof on
the first non-zero VLAN ADD. During the re-add phase after up,
the filter list is transiently incomplete; traffic for VLANs not
yet re-added gets dropped by anti-spoof.

- Rapid down/up can overlap with pending DEL messages. The old code
used DISABLE/INACTIVE states to track this, but the DISABLE state
could overwrite a concurrent REMOVE from userspace, causing the
filter to be restored instead of deleted.

- Namespace moves trigger implicit ndo_vlan_rx_kill_vid() calls
concurrent with the down/up sequence. The DEL from the namespace
teardown races with the DISABLE from iavf_down(), and the filter
can end up leaked in num_vlan_filters with no associated netdev.

After reset, VF-configured VLAN filters are properly re-added via
the VIRTCHNL_OP_GET_VF_RESOURCES / GET_OFFLOAD_VLAN_V2_CAPS response
handlers, which unconditionally set all filters to ADD state. This
path is unaffected by these changes.

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.

v2: Retarget from iwl-next to iwl-net; these are bug fixes.
Rebase on current net tree (conflict resolved).

Petr Oros (4):
iavf: rename IAVF_VLAN_IS_NEW to IAVF_VLAN_ADDING
iavf: stop removing VLAN filters from PF on interface down
iavf: wait for PF confirmation before removing VLAN filters
iavf: add VIRTCHNL_OP_ADD_VLAN to success completion handler

drivers/net/ethernet/intel/iavf/iavf.h | 9 +--
drivers/net/ethernet/intel/iavf/iavf_main.c | 52 +++----------
.../net/ethernet/intel/iavf/iavf_virtchnl.c | 76 +++++++++----------
3 files changed, 52 insertions(+), 85 deletions(-)

--
2.52.0