lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <78bd0e54-4ee3-bd3c-2154-9eb8b9a70497@blackwall.org>
Date:   Tue, 20 Sep 2022 12:16:26 +0300
From:   Nikolay Aleksandrov <razor@...ckwall.org>
To:     Sevinj Aghayeva <sevinj.aghayeva@...il.com>, netdev@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>, aroulin@...dia.com,
        sbrivio@...hat.com, roopa@...dia.com,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org,
        bridge@...ts.linux-foundation.org
Subject: Re: [PATCH RFC net-next 0/5] net: vlan: fix bridge binding behavior
 and add selftests

On 17/09/2022 23:17, Sevinj Aghayeva wrote:
> 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 (5):
>   net: core: export call_netdevice_notifiers_info
>   net: core: introduce a new notifier for link-type-specific changes
>   net: 8021q: notify bridge module of bridge-binding flag change
>   net: bridge: handle link-type-specific changes in the bridge module
>   selftests: net: tests for bridge binding behavior
> 
>  include/linux/if_vlan.h                       |   4 +
>  include/linux/netdevice.h                     |   3 +
>  include/linux/notifier_info.h                 |  21 +++
>  net/8021q/vlan.h                              |   2 +-
>  net/8021q/vlan_dev.c                          |  20 ++-
>  net/bridge/br.c                               |   5 +
>  net/bridge/br_private.h                       |   7 +
>  net/bridge/br_vlan.c                          |  18 +++
>  net/core/dev.c                                |   7 +-
>  tools/testing/selftests/net/Makefile          |   1 +
>  .../selftests/net/bridge_vlan_binding_test.sh | 143 ++++++++++++++++++
>  11 files changed, 223 insertions(+), 8 deletions(-)
>  create mode 100644 include/linux/notifier_info.h
>  create mode 100755 tools/testing/selftests/net/bridge_vlan_binding_test.sh
> 

The set looks good to me, the bridge and vlan direct dependency is gone and
the new notification type is used for passing link type specific info.

If the others are ok with it I think you can send it as non-RFC, but I'd give it
a few more days at least. :)

Thanks,
 Nik

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ