From: Sabrina Dubroca <sd@queasysnail.net>
To: ehakim@nvidia.com, atenart@kernel.org
Cc: 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: Mon, 9 Jan 2023 16:14:32 +0100 [thread overview]
Message-ID: <Y7wvWOZYL1t7duV/@hog> (raw)
In-Reply-To: <20230109085557.10633-2-ehakim@nvidia.com>
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]) {
... 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?
--
Sabrina
next prev parent reply other threads:[~2023-01-09 15:19 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 [this message]
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
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=Y7wvWOZYL1t7duV/@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.