From: Sabrina Dubroca <sd@queasysnail.net>
To: Antoine Tenart <atenart@kernel.org>
Cc: ehakim@nvidia.com, netdev@vger.kernel.org, raeds@nvidia.com,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com
Subject: Re: [PATCH net-next v7 1/2] macsec: add support for IFLA_MACSEC_OFFLOAD in macsec_changelink
Date: Tue, 10 Jan 2023 11:44:13 +0100 [thread overview]
Message-ID: <Y71BfSFAtZJoker5@hog> (raw)
In-Reply-To: <167334021775.17820.2386827809582589477@kwain.local>
2023-01-10, 09:43:37 +0100, Antoine Tenart wrote:
> Quoting Sabrina Dubroca (2023-01-09 16:14:32)
> > 2023-01-09, 10:55:56 +0200, ehakim@nvidia.com wrote:
> > > @@ -3840,6 +3835,12 @@ static int macsec_changelink(struct net_device *dev, struct nlattr *tb[],
> > > if (ret)
> > > goto cleanup;
> > >
> > > + if (data[IFLA_MACSEC_OFFLOAD]) {
> > > + ret = macsec_update_offload(dev, nla_get_u8(data[IFLA_MACSEC_OFFLOAD]));
> > > + if (ret)
> > > + goto cleanup;
> > > + }
> > > +
> > > /* If h/w offloading is available, propagate to the device */
> > > if (macsec_is_offloaded(macsec)) {
> > > const struct macsec_ops *ops;
> >
> > There's a missing rollback of the offloading status in the (probably
> > quite unlikely) case that mdo_upd_secy fails, no? We can't fail
> > macsec_get_ops because macsec_update_offload would have failed
> > already, but I guess the driver could fail in mdo_upd_secy, and then
> > "goto cleanup" doesn't restore the offloading state. Sorry I didn't
> > notice this earlier.
> >
> > In case the IFLA_MACSEC_OFFLOAD attribute is provided and we're
> > enabling offload, we also end up calling the driver's mdo_add_secy,
> > and then immediately afterwards mdo_upd_secy, which probably doesn't
> > make much sense.
> >
> > Maybe we could turn that into:
> >
> > if (data[IFLA_MACSEC_OFFLOAD]) {
>
> If data[IFLA_MACSEC_OFFLOAD] is provided but doesn't change the
> offloading state, then macsec_update_offload will return early and
> mdo_upd_secy won't be called.
Ouch, thanks for catching this.
>
> > ... macsec_update_offload
> > } else if (macsec_is_offloaded(macsec)) {
> > /* If h/w offloading is available, propagate to the device */
> > ... mdo_upd_secy
> > }
> >
> > Antoine, does that look reasonable to you?
>
> But yes I agree we can improve the logic. Maybe something like:
>
> prev_offload = macsec->offload;
> offload = data[IFLA_MACSEC_OFFLOAD];
That needs to be under if (data[IFLA_MACSEC_OFFLOAD]) and then the
rest gets a bit messy.
>
> if (prev_offload != offload) {
> macsec_update_offload(...)
> } else if (macsec_is_offloaded(macsec)) {
> ...
> prev_offload can be used to restore the offloading state on
> failure here.
> }
We also have a prev != new test at the start of macsec_update_offload,
the duplication is a bit ugly. We could move it out and then only call
macsec_update_offload when there is a change to do, both from
macsec_changelink and macsec_upd_offload.
Since we don't need to restore in the second branch, and we can only
fetch IFLA_MACSEC_OFFLOAD when it's present, maybe:
change = false;
if (data[IFLA_MACSEC_OFFLOAD]) {
offload = nla_get_u8(data[IFLA_MACSEC_OFFLOAD]);
if (macsec->offload != offload) {
change = true;
macsec_update_offload ...cleanup
}
}
if (!change && macsec_is_offloaded(macsec)) {
...
}
Or let macsec_update_offload do the macsec->offload != offload test
and pass &change so that changelink can know what to do next.
--
Sabrina
next prev parent reply other threads:[~2023-01-10 10:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-09 8:55 [PATCH net-next v7 0/2] Add support to offload macsec using netlink update ehakim
2023-01-09 8:55 ` [PATCH net-next v7 1/2] macsec: add support for IFLA_MACSEC_OFFLOAD in macsec_changelink ehakim
2023-01-09 15:14 ` Sabrina Dubroca
2023-01-10 8:43 ` Antoine Tenart
2023-01-10 9:05 ` Emeel Hakim
[not found] ` <167334656781.17820.3219445403317381657@kwain.local>
2023-01-10 11:46 ` Sabrina Dubroca
2023-01-10 10:44 ` Sabrina Dubroca [this message]
2023-01-10 13:55 ` Antoine Tenart
2023-01-10 16:16 ` Emeel Hakim
2023-01-09 8:55 ` [PATCH net-next v7 2/2] macsec: dump IFLA_MACSEC_OFFLOAD attribute as part of macsec dump ehakim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y71BfSFAtZJoker5@hog \
--to=sd@queasysnail.net \
--cc=atenart@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=ehakim@nvidia.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=raeds@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.