Re: [PATCH ipsec v2 1/2] bond: Use xfrm_state_migrate to migrate SAs

[Steffen Klassert <steffen.klassert@secunet.com>]

On Thu, Nov 20, 2025 at 12:36:16PM +0100, Sabrina Dubroca wrote:
> 2025-11-17, 12:48:20 +0000, Cosmin Ratiu wrote:
> > On Fri, 2025-11-14 at 13:56 +0100, Sabrina Dubroca wrote:
> 
> > All other callers of xfrm_state_delete() don't care about free, it will
> > be done when there are no more refs.
> > 
> > So right now for devices that implement xdo_dev_state_free(), there's
> > distinct behavior of what happens when xfrm_state_delete gets called
> > 
> > So right now, there's a difference in behavior for what happens with
> > in-flight packets when xfrm_state_delete() is called:
> > 1. On devs which delete the dev state in xdo_dev_state_free(), in-
> > flight packets are not affected.
> > 2. On devs which delete the dev state in xdo_dev_state_delete(), in-
> > flight packets will see the xs yanked from underneath them.
> > 
> > This makes me ask the question: Is there a point to the
> > xdo_dev_state_delete() callback any more? Couldn't we consolidate on
> > having a single callback to free the offloaded xfrm_state when there
> > are no more references to it? This would simplify the delete+free dance
> > and would leave proper cleanup for the xs reference counting.
> > 
> > What am I missing?
> 
> I don't know. Maybe it's a leftover of the initial offload
> implementation/drivers that we don't need anymore? Steffen?

The xfrm states are deleted in two stages. xfrm_state_delete
removes the states from the lists so they don't get used anymore.
In a second step the states are freed once all inflight packets
that used the state left the system. The xdo_dev_state_delete
and xdo_dev_state_free were an offer to the driver to do something
at both stages. I don't remember anymore how it was used in the
beginning. But if one callback is sufficient for all the drivers,
I'm ok with having just one callback.