From: Sevinj Aghayeva <sevinj.aghayeva@gmail.com> To: netdev@vger.kernel.org Cc: aroulin@nvidia.com, sbrivio@redhat.com, roopa@nvidia.com, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Nikolay Aleksandrov <razor@blackwall.org>, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, Sevinj Aghayeva <sevinj.aghayeva@gmail.com> Subject: [PATCH RFC net-next 0/3] net: vlan: fix bridge binding behavior and add selftests Date: Tue, 9 Aug 2022 23:11:18 -0400 [thread overview] Message-ID: <cover.1660100506.git.sevinj.aghayeva@gmail.com> (raw) When bridge binding is enabled for a vlan interface, it is expected that the link state of the vlan interface will track the subset of the ports that are also members of the corresponding vlan, rather than that of all ports. Currently, this feature works as expected when a vlan interface is created with bridge binding enabled: ip link add link br name vlan10 type vlan id 10 protocol 802.1q \ bridge_binding on However, the feature does not work when a vlan interface is created with bridge binding disabled, and then enabled later: ip link add link br name vlan10 type vlan id 10 protocol 802.1q \ bridge_binding off ip link set vlan10 type vlan bridge_binding on After these two commands, the link state of the vlan interface continues to track that of all ports, which is inconsistent and confusing to users. This series fixes this bug and introduces two tests for the valid behavior. Sevinj Aghayeva (3): net: core: export call_netdevice_notifiers_info net: 8021q: fix bridge binding behavior for vlan interfaces selftests: net: tests for bridge binding behavior include/linux/netdevice.h | 2 + net/8021q/vlan.h | 2 +- net/8021q/vlan_dev.c | 25 ++- net/core/dev.c | 7 +- tools/testing/selftests/net/Makefile | 1 + .../selftests/net/bridge_vlan_binding_test.sh | 143 ++++++++++++++++++ 6 files changed, 172 insertions(+), 8 deletions(-) create mode 100755 tools/testing/selftests/net/bridge_vlan_binding_test.sh -- 2.25.1
WARNING: multiple messages have this Message-ID (diff)
From: Sevinj Aghayeva <sevinj.aghayeva@gmail.com> To: netdev@vger.kernel.org Cc: aroulin@nvidia.com, Nikolay Aleksandrov <razor@blackwall.org>, bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org, sbrivio@redhat.com, Eric Dumazet <edumazet@google.com>, Sevinj Aghayeva <sevinj.aghayeva@gmail.com>, roopa@nvidia.com, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, "David S. Miller" <davem@davemloft.net> Subject: [Bridge] [PATCH RFC net-next 0/3] net: vlan: fix bridge binding behavior and add selftests Date: Tue, 9 Aug 2022 23:11:18 -0400 [thread overview] Message-ID: <cover.1660100506.git.sevinj.aghayeva@gmail.com> (raw) When bridge binding is enabled for a vlan interface, it is expected that the link state of the vlan interface will track the subset of the ports that are also members of the corresponding vlan, rather than that of all ports. Currently, this feature works as expected when a vlan interface is created with bridge binding enabled: ip link add link br name vlan10 type vlan id 10 protocol 802.1q \ bridge_binding on However, the feature does not work when a vlan interface is created with bridge binding disabled, and then enabled later: ip link add link br name vlan10 type vlan id 10 protocol 802.1q \ bridge_binding off ip link set vlan10 type vlan bridge_binding on After these two commands, the link state of the vlan interface continues to track that of all ports, which is inconsistent and confusing to users. This series fixes this bug and introduces two tests for the valid behavior. Sevinj Aghayeva (3): net: core: export call_netdevice_notifiers_info net: 8021q: fix bridge binding behavior for vlan interfaces selftests: net: tests for bridge binding behavior include/linux/netdevice.h | 2 + net/8021q/vlan.h | 2 +- net/8021q/vlan_dev.c | 25 ++- net/core/dev.c | 7 +- tools/testing/selftests/net/Makefile | 1 + .../selftests/net/bridge_vlan_binding_test.sh | 143 ++++++++++++++++++ 6 files changed, 172 insertions(+), 8 deletions(-) create mode 100755 tools/testing/selftests/net/bridge_vlan_binding_test.sh -- 2.25.1
next reply other threads:[~2022-08-10 3:12 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-08-10 3:11 Sevinj Aghayeva [this message] 2022-08-10 3:11 ` [Bridge] [PATCH RFC net-next 0/3] net: vlan: fix bridge binding behavior and add selftests Sevinj Aghayeva 2022-08-10 3:11 ` [PATCH RFC net-next 1/3] net: core: export call_netdevice_notifiers_info Sevinj Aghayeva 2022-08-10 3:11 ` [Bridge] " Sevinj Aghayeva 2022-08-10 3:11 ` [PATCH RFC net-next 2/3] net: 8021q: fix bridge binding behavior for vlan interfaces Sevinj Aghayeva 2022-08-10 3:11 ` [Bridge] " Sevinj Aghayeva 2022-08-10 3:11 ` [PATCH RFC net-next 3/3] selftests: net: tests for bridge binding behavior Sevinj Aghayeva 2022-08-10 3:11 ` [Bridge] " Sevinj Aghayeva 2022-08-10 8:54 ` [PATCH RFC net-next 0/3] net: vlan: fix bridge binding behavior and add selftests Nikolay Aleksandrov 2022-08-10 8:54 ` [Bridge] " Nikolay Aleksandrov 2022-08-10 14:42 ` Sevinj Aghayeva 2022-08-10 14:50 ` Nikolay Aleksandrov 2022-08-10 14:50 ` [Bridge] " Nikolay Aleksandrov 2022-08-10 15:00 ` Sevinj Aghayeva 2022-08-10 15:00 ` [Bridge] " Sevinj Aghayeva 2022-08-10 15:10 ` Nikolay Aleksandrov 2022-08-10 15:10 ` [Bridge] " Nikolay Aleksandrov 2022-08-10 15:21 ` Sevinj Aghayeva 2022-08-10 15:21 ` [Bridge] " Sevinj Aghayeva 2022-08-12 15:30 ` Sevinj Aghayeva 2022-08-12 15:30 ` [Bridge] " Sevinj Aghayeva 2022-08-14 7:38 ` Nikolay Aleksandrov 2022-08-14 7:38 ` [Bridge] " Nikolay Aleksandrov 2022-08-18 11:50 ` Sevinj Aghayeva 2022-08-18 11:50 ` [Bridge] " Sevinj Aghayeva 2022-08-18 12:00 ` Nikolay Aleksandrov 2022-08-18 12:00 ` [Bridge] " Nikolay Aleksandrov 2022-08-20 11:33 ` Sevinj Aghayeva 2022-08-20 11:33 ` [Bridge] " Sevinj Aghayeva 2022-08-22 8:01 ` Nikolay Aleksandrov 2022-08-22 8:01 ` [Bridge] " Nikolay Aleksandrov 2022-08-22 23:18 ` Sevinj Aghayeva 2022-08-29 20:22 ` Sevinj Aghayeva 2022-08-31 10:16 ` Nikolay Aleksandrov 2022-08-31 10:16 ` [Bridge] " Nikolay Aleksandrov
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=cover.1660100506.git.sevinj.aghayeva@gmail.com \ --to=sevinj.aghayeva@gmail.com \ --cc=aroulin@nvidia.com \ --cc=bridge@lists.linux-foundation.org \ --cc=davem@davemloft.net \ --cc=edumazet@google.com \ --cc=kuba@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ --cc=razor@blackwall.org \ --cc=roopa@nvidia.com \ --cc=sbrivio@redhat.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: linkBe 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.