From: Sabrina Dubroca <sd@queasysnail.net>
To: Radu Rendec <radu.rendec@gmail.com>
Cc: netdev@vger.kernel.org, David Miller <davem@davemloft.net>,
Patrick Talbert <ptalbert@redhat.com>
Subject: Re: [PATCH 1/1] macsec: reflect the master interface state
Date: Wed, 19 Sep 2018 17:24:25 +0200 [thread overview]
Message-ID: <20180919152425.GA3046@bistromath.localdomain> (raw)
In-Reply-To: <20180919001612.2636-2-radu.rendec@gmail.com>
Hello,
2018-09-18, 20:16:12 -0400, Radu Rendec wrote:
> This patch makes macsec interfaces reflect the state of the underlying
> interface: if the master interface changes state to up/down, the macsec
> interface changes its state accordingly.
I got a separate report of the same issue and I've been looking in
that area too.
> This closes a loophole in the macsec interface state logic: the macsec
> interface cannot be brought up if the master interface is down (the
> operation is rejected with ENETDOWN); however, if the macsec interface
> is brought up while the master interface is up and then the master
> interface goes down, the macsec interface stays up.
Yes, that's a bit unfortunate. I was wondering if we should just allow
setting the device up, and let link state handle the rest.
> Reflecting the master interface state can also be useful if the macsec
> interface is used as a bridge port: if the master (physical) interface
> goes down, the state propagates through the macsec interface to the
> bridge module, which can react to the state change (for example if it
> runs STP).
>
> The patch does nothing original. The same logic is implemented for vlan
> interfaces in vlan_device_event() in net/8021q/vlan.c. In fact, the code
> was copied and adapted from there.
It's missing small parts of link state handling that I have been
testing, mainly when creating a new device.
> Signed-off-by: Radu Rendec <radu.rendec@gmail.com>
> ---
> drivers/net/macsec.c | 57 +++++++++++++++++++++++++++++++++++---------
> 1 file changed, 46 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c
> index 7de88b33d5b9..cb93a1290f85 100644
> --- a/drivers/net/macsec.c
> +++ b/drivers/net/macsec.c
> @@ -3486,20 +3486,21 @@ static int macsec_notify(struct notifier_block *this, unsigned long event,
> void *ptr)
> {
> struct net_device *real_dev = netdev_notifier_info_to_dev(ptr);
> - LIST_HEAD(head);
> + struct macsec_dev *m;
> + struct macsec_rxh_data *rxd;
>
> if (!is_macsec_master(real_dev))
> return NOTIFY_DONE;
>
> + rxd = macsec_data_rtnl(real_dev);
> +
> switch (event) {
> case NETDEV_UNREGISTER: {
> - struct macsec_dev *m, *n;
> - struct macsec_rxh_data *rxd;
> + struct macsec_dev *n;
> + LIST_HEAD(head);
>
> - rxd = macsec_data_rtnl(real_dev);
> - list_for_each_entry_safe(m, n, &rxd->secys, secys) {
> + list_for_each_entry_safe(m, n, &rxd->secys, secys)
> macsec_common_dellink(m->secy.netdev, &head);
> - }
Please don't mix coding style changes with bug fixes.
[...]
> + case NETDEV_DOWN: {
> + struct net_device *dev, *tmp;
> + LIST_HEAD(close_list);
> +
> + list_for_each_entry(m, &rxd->secys, secys) {
> + dev = m->secy.netdev;
> +
> + if (dev->flags & IFF_UP)
> + list_add(&dev->close_list, &close_list);
> + }
> +
> + dev_close_many(&close_list, false);
> +
> + list_for_each_entry_safe(dev, tmp, &close_list, close_list) {
> + netif_stacked_transfer_operstate(real_dev, dev);
> + list_del_init(&dev->close_list);
> + }
> + list_del(&close_list);
> + break;
My version of the patch only does netif_stacked_transfer_operstate(),
and skips setting the device administratively down (ie, same as
NETDEV_CHANGE).
> }
> + case NETDEV_UP:
> + list_for_each_entry(m, &rxd->secys, secys) {
> + struct net_device *dev = m->secy.netdev;
> + int flags = dev_get_flags(dev);
> +
> + if (!(flags & IFF_UP)) {
> + dev_change_flags(dev, flags | IFF_UP);
> + netif_stacked_transfer_operstate(real_dev, dev);
> + }
> + }
> + break;
I don't like that this completely ignores whether the device was done
independently of the lower link. Maybe the administrator actually
wants the macsec device down, regardless of state changes on the lower
device.
I know it's consistent with what vlan is doing, but I'm not convinced
macsec should adopt this behavior.
> }
>
> return NOTIFY_OK;
> --
> 2.17.1
>
--
Sabrina
next prev parent reply other threads:[~2018-09-19 21:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-19 0:16 [PATCH 0/1] macsec: reflect the master interface state Radu Rendec
2018-09-19 0:16 ` [PATCH 1/1] " Radu Rendec
2018-09-19 15:24 ` Sabrina Dubroca [this message]
2018-09-19 16:44 ` Radu Rendec
2018-10-01 12:52 ` Sabrina Dubroca
2018-10-28 21:14 ` Radu Rendec
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=20180919152425.GA3046@bistromath.localdomain \
--to=sd@queasysnail.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=ptalbert@redhat.com \
--cc=radu.rendec@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).