From: David Miller <davem@davemloft.net>
To: vincent@bernat.im
Cc: stephen@networkplumber.org, bridge@lists.linux-foundation.org,
netdev@vger.kernel.org, dsahern@gmail.com
Subject: Re: [PATCH net-next v2] bridge: also trigger RTM_NEWLINK when interface is released from bridge
Date: Wed, 20 Sep 2017 14:09:56 -0700 (PDT) [thread overview]
Message-ID: <20170920.140956.781667692297467325.davem@davemloft.net> (raw)
In-Reply-To: <20170916141833.28344-1-vincent@bernat.im>
From: Vincent Bernat <vincent@bernat.im>
Date: Sat, 16 Sep 2017 16:18:33 +0200
David, I am CC:'ing you because you've done work in this area over the
past year. I'm applying this patch, it's been sitting since the 16th
and likes entirely correct to me. But if you have objections just let
me know.
> Currently, when an interface is released from a bridge via
> ioctl(), we get a RTM_DELLINK event through netlink:
>
> Deleted 2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 6e:23:c2:54:3a:b3
>
> Userspace has to interpret that as a removal from the bridge, not as a
> complete removal of the interface. When an bridged interface is
> completely removed, we get two events:
>
> Deleted 2: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
> link/ether 6e:23:c2:54:3a:b3
> Deleted 2: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
> link/ether 6e:23:c2:54:3a:b3 brd ff:ff:ff:ff:ff:ff
>
> In constrast, when an interface is released from a bond, we get a
> RTM_NEWLINK with only the new characteristics (no master):
>
> 3: dummy1: <BROADCAST,NOARP,SLAVE,UP,LOWER_UP> mtu 1500 qdisc noqueue master bond0 state UNKNOWN group default
> link/ether ae:dc:7a:8c:9a:3c brd ff:ff:ff:ff:ff:ff
> 3: dummy1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
> link/ether ae:dc:7a:8c:9a:3c brd ff:ff:ff:ff:ff:ff
> 4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
> link/ether ae:dc:7a:8c:9a:3c brd ff:ff:ff:ff:ff:ff
> 3: dummy1: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN group default
> link/ether ae:dc:7a:8c:9a:3c brd ff:ff:ff:ff:ff:ff
> 3: dummy1: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN group default
> link/ether ca:c8:7b:66:f8:25 brd ff:ff:ff:ff:ff:ff
> 4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
> link/ether ae:dc:7a:8c:9a:3c brd ff:ff:ff:ff:ff:ff
>
> Userland may be confused by the fact we say a link is deleted while
> its characteristics are only modified. A first solution would have
> been to turn the RTM_DELLINK event in del_nbp() into a RTM_NEWLINK
> event. However, maybe some piece of userland is relying on this
> RTM_DELLINK to detect when a bridged interface is released. Instead,
> we also emit a RTM_NEWLINK event once the interface is
> released (without master info).
>
> Deleted 2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master bridge0 state UNKNOWN
> link/ether 8a:bb:e7:94:b1:f8
> 2: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
> link/ether 8a:bb:e7:94:b1:f8 brd ff:ff:ff:ff:ff:ff
>
> This is done only when using ioctl(). When using Netlink, such an
> event is already automatically emitted in do_setlink().
>
> Signed-off-by: Vincent Bernat <vincent@bernat.im>
Applied, thank you.
next prev parent reply other threads:[~2017-09-20 21:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-15 19:38 [PATCH net-next v1] bridge: also trigger RTM_NEWLINK when interface is released from bridge Vincent Bernat
2017-09-15 21:08 ` Vincent Bernat
2017-09-16 14:18 ` [PATCH net-next v2] " Vincent Bernat
2017-09-20 21:09 ` David Miller [this message]
2017-09-20 21:57 ` David Ahern
2017-09-20 22:12 ` Vincent Bernat
2017-09-20 22:41 ` David Miller
2017-09-20 23:21 ` Stephen Hemminger
2017-09-21 10:04 ` Vincent Bernat
2017-09-21 15:09 ` Roopa Prabhu
2017-09-21 15:31 ` Vincent Bernat
2017-09-21 10:05 ` [net-next v3] bridge: trigger RTM_NEWLINK when interface is modified by bridge ioctl Vincent Bernat
2017-09-21 15:15 ` Stephen Hemminger
2017-09-21 15:45 ` Vincent Bernat
2017-09-21 16:43 ` David Ahern
2017-09-21 17:20 ` Roopa Prabhu
2017-09-21 17:29 ` David Ahern
2017-09-21 22:45 ` David Miller
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=20170920.140956.781667692297467325.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=bridge@lists.linux-foundation.org \
--cc=dsahern@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=vincent@bernat.im \
/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).