RE: [Intel-wired-lan] [PATCH iwl-next 4/4] iavf: harden VLAN filter state machine race handling

[Romanowski, Rafal]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@xxxxxxxxxx> On Behalf Of
> Loktionov, Aleksandr
> Sent: Monday, March 16, 2026 12:38 PM
> To: Oros, Petr <poros@xxxxxxxxxx>; netdev@xxxxxxxxxxxxxxx
> Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@xxxxxxxxx>; Eric Dumazet
> <edumazet@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; Andrew Lunn
> <andrew+netdev@xxxxxxx>; Nguyen, Anthony L <anthony.l.nguyen@xxxxxxxxx>;
> intel-wired-lan@xxxxxxxxxxxxxxxx; Keller, Jacob E <jacob.e.keller@xxxxxxxxx>;
> Jakub Kicinski <kuba@xxxxxxxxxx>; Paolo Abeni <pabeni@xxxxxxxxxx>; David S.
> Miller <davem@xxxxxxxxxxxxx>
> Subject: Re: [Intel-wired-lan] [PATCH iwl-next 4/4] iavf: harden VLAN filter state
> machine race handling
> 
> 
> 
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@xxxxxxxxxx> On Behalf
> > Of Petr Oros
> > Sent: Monday, March 16, 2026 11:42 AM
> > To: netdev@xxxxxxxxxxxxxxx
> > Cc: Kitszel, Przemyslaw <przemyslaw.kitszel@xxxxxxxxx>; Eric Dumazet
> > <edumazet@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; Andrew Lunn
> > <andrew+netdev@xxxxxxx>; Nguyen, Anthony L
> > <anthony.l.nguyen@xxxxxxxxx>; intel-wired-lan@xxxxxxxxxxxxxxxx;
> > Keller, Jacob E <jacob.e.keller@xxxxxxxxx>; Jakub Kicinski
> > <kuba@xxxxxxxxxx>; Paolo Abeni <pabeni@xxxxxxxxxx>; David S. Miller
> > <davem@xxxxxxxxxxxxx>
> > Subject: [Intel-wired-lan] [PATCH iwl-next 4/4] iavf: harden VLAN
> > filter state machine race handling
> >
> > Address remaining race windows in the VLAN filter state machine that
> > were identified during cross-state analysis of ADD and DEL paths.
> >
> > 1. Add VIRTCHNL_OP_ADD_VLAN to the success completion handler.
> >
> >    The V1 ADD_VLAN opcode had no success handler -- filters sent via
> > V1
> >    stayed in ADDING state permanently.  Add a fallthrough case so V1
> >    filters also transition ADDING -> ACTIVE on PF confirmation.
> >
> >    Critically, add an `if (v_retval) break` guard: the error switch
> >    in iavf_virtchnl_completion() does NOT return after handling
> > errors,
> >    it falls through to the success switch.  Without this guard, a
> >    PF-rejected ADD would incorrectly mark ADDING filters as ACTIVE,
> >    creating a driver/HW mismatch where the driver believes the filter
> >    is installed but the PF never accepted it.
> >
> >    For V2, this is harmless: iavf_vlan_add_reject() in the error
> >    block already kfree'd all ADDING filters, so the success handler
> >    finds nothing to transition.
> >
> > 2. Skip DEL on filters already in REMOVING state.
> >
> >    In iavf_del_vlan(), if a filter is in IAVF_VLAN_REMOVING (DEL
> >    already sent to PF, waiting for response), do not overwrite to
> >    REMOVE and schedule a redundant DEL.  The pending DEL's
> >    completion handler will either kfree the filter (PF confirms)
> >    or revert to ACTIVE (PF rejects).
> >
> >    Without this, the sequence DEL(pending) -> user-del -> second DEL
> >    could result in PF returning an error for the second DEL (filter
> >    already gone), causing the completion handler to incorrectly revert
> >    a deleted filter back to ACTIVE.
> >
> > Signed-off-by: Petr Oros <poros@xxxxxxxxxx>
> > ---
> >  drivers/net/ethernet/intel/iavf/iavf_main.c     | 5 ++++-
> >  drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 4 ++++
> >  2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c
> > b/drivers/net/ethernet/intel/iavf/iavf_main.c
> > index 89e5aae20d5573..1ffc0ce3f35602 100644
> > --- a/drivers/net/ethernet/intel/iavf/iavf_main.c
> > +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
> > @@ -816,11 +816,14 @@ static void iavf_del_vlan(struct iavf_adapter


Tested-by: Rafal Romanowski <rafal.romanowski@xxxxxxxxx>