Messages in this thread Patch in this message | | | Date | Wed, 18 Dec 2019 15:01:31 +0100 | From | Antoine Tenart <> | Subject | Re: [EXT] [PATCH net-next v3 05/15] net: macsec: hardware offloading infrastructure |
| |
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
| |