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

-- 
2.34.1

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

On Tue, 20 Sep 2022 12:16:26 +0300 Nikolay Aleksandrov wrote:
> 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.

IDK, vlan knows it's calling the bridge:

+	if ((vlan->flags ^ old_flags) & VLAN_FLAG_BRIDGE_BINDING &&
+	    netif_is_bridge_master(vlan->real_dev)) {

bridge knows it's vlan calling:

+	if (is_vlan_dev(dev)) {
+		br_vlan_device_event(dev, event, ptr);

going thru the generic NETDEV notifier seems odd.

If this is just to avoid the dependency we can perhaps add a stub 
like net/ipv4/udp_tunnel_stub.c ?

> 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. :)

On 21/09/2022 02:29, Jakub Kicinski wrote:
> On Tue, 20 Sep 2022 12:16:26 +0300 Nikolay Aleksandrov wrote:
>> 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.
> 
> IDK, vlan knows it's calling the bridge:
> 
> +	if ((vlan->flags ^ old_flags) & VLAN_FLAG_BRIDGE_BINDING &&
> +	    netif_is_bridge_master(vlan->real_dev)) {
> 

This one is more of an optimization so notifications are sent only when the bridge
is involved, it can be removed if other interested parties show up.

> bridge knows it's vlan calling:
> 
> +	if (is_vlan_dev(dev)) {
> +		br_vlan_device_event(dev, event, ptr);
> 
> going thru the generic NETDEV notifier seems odd.
> 
> If this is just to avoid the dependency we can perhaps add a stub 
> like net/ipv4/udp_tunnel_stub.c ?
> 

I suggested the notifier to be more generic and be able to re-use it for other link types although
I don't have other use cases in mind right now. Stubs are an alternative as long as they and
their lifetime are properly managed. I don't have a strong preference here so if you prefer
stubs I'm good.

>> 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. :)

Cheers,
 Nik

On Wed, 21 Sep 2022 07:45:07 +0300 Nikolay Aleksandrov wrote:
> > IDK, vlan knows it's calling the bridge:
> > 
> > +	if ((vlan->flags ^ old_flags) & VLAN_FLAG_BRIDGE_BINDING &&
> > +	    netif_is_bridge_master(vlan->real_dev)) {
> 
> This one is more of an optimization so notifications are sent only when the bridge
> is involved, it can be removed if other interested parties show up.
> 
> > bridge knows it's vlan calling:
> > 
> > +	if (is_vlan_dev(dev)) {
> > +		br_vlan_device_event(dev, event, ptr);
> > 
> > going thru the generic NETDEV notifier seems odd.
> > 
> > If this is just to avoid the dependency we can perhaps add a stub 
> > like net/ipv4/udp_tunnel_stub.c ?
> 
> I suggested the notifier to be more generic and be able to re-use it for other link types although
> I don't have other use cases in mind right now. Stubs are an alternative as long as they and
> their lifetime are properly managed. I don't have a strong preference here so if you prefer
> stubs I'm good.

Yup, stub seems simpler and more efficient to me. Only time will
tell if indeed this ntf type would have been reused further.. 🤷