Re: [EXT] [PATCH net-next v3 05/15] net: macsec: hardware offloading infrastructure

[Antoine Tenart]

Hello Igor,

On Wed, Dec 18, 2019 at 01:40:39PM +0000, Igor Russkikh wrote:
> > @@ -2922,7 +3300,27 @@ static int macsec_changelink(struct net_device
> > *dev, struct nlattr *tb[],
> >  	    data[IFLA_MACSEC_PORT])
> >  		return -EINVAL;
> >  
> > -	return macsec_changelink_common(dev, data);
> > +	/* If h/w offloading is available, propagate to the device */
> > +	if (macsec_is_offloaded(macsec)) {
> > +		const struct macsec_ops *ops;
> > +		struct macsec_context ctx;
> > +		int ret;
> > +
> > +		ops = macsec_get_ops(netdev_priv(dev), &ctx);
> > +		if (!ops)
> > +			return -EOPNOTSUPP;
> > +
> > +		ctx.secy = &macsec->secy;
> > +		ret = macsec_offload(ops->mdo_upd_secy, &ctx);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> > +	ret = macsec_changelink_common(dev, data);
> 
> In our mac driver verification we see that propagating upd_secy to
> device before doing macsec_changelink_common is actually useless,
> since in this case underlying device can't fetch any of the updated
> parameters from the macsec structures.
> 
> Isn't it logical first doing `macsec_changelink_common` and then
> propagate the event?

Doing the macsec_changelink_common after propagating the event to the
device driver was done to ease the fail case scenario (it's quite hard
to revert macsec_changelink_common). But then you're right that many
parameters are set by macsec_changelink_common, which means it must be
performed before the propagation of the upd_secy event.

I think the solution is to keep a copy of unmodified secy and tx_sc, and
in case of failure to revert the operation by copying the whole
structures back. That would allow to move macsec_changelink_common up.
Would that work for you?

Thanks for spotting this!
Antoine

-- 
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com