[PATCH net-next 0/4] net: support binding vlan dev link state to vlan member bridge ports

[PATCH net-next 0/4] net: support binding vlan dev link state to vlan member bridge ports

[Mike Manning]

For vlan filtering on bridges, the bridge may also have vlan devices
as upper devices. For switches, these are used to provide L3 packet
processing for ports that are members of a given vlan.

While it is correct that the admin state for these vlan devices is
either set directly for the device or inherited from the lower device,
the link state is also transferred from the lower device. So this is
always up if the bridge is in admin up state and there is at least one
bridge port that is up, regardless of the vlan that the port is in.

The link state of the vlan device may need to track only the state of
the subset of ports that are also members of the corresponding vlan,
rather than that of all ports.

This series provides an optional vlan flag so that the link state of
the vlan device is only up if there is at least one bridge port that is
up AND is a member of the corresponding vlan.


Mike Manning (4):
  vlan: support binding link state to vlan member bridge ports
  vlan: do not transfer link state in vlan bridge binding mode
  bridge: support binding vlan dev link state to vlan member bridge
    ports
  bridge: update vlan dev state when port added to or deleted from vlan

 include/uapi/linux/if_vlan.h |   9 +--
 net/8021q/vlan.c             |  18 +++--
 net/8021q/vlan_dev.c         |  22 +++---
 net/8021q/vlan_netlink.c     |   3 +-
 net/bridge/br.c              |  23 ++++--
 net/bridge/br_private.h      |  17 +++++
 net/bridge/br_vlan.c         | 166 +++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 237 insertions(+), 21 deletions(-)

-- 
2.11.0

[PATCH net-next 1/4] vlan: support binding link state to vlan member bridge ports

[Mike Manning]

In the case of vlan filtering on bridges, the bridge may also have the
corresponding vlan devices as upper devices. Currently the link state
of vlan devices is transferred from the lower device. So this is up if
the bridge is in admin up state and there is at least one bridge port
that is up, regardless of the vlan that the port is a member of.

The link state of the vlan device may need to track only the state of
the subset of ports that are also members of the corresponding vlan,
rather than that of all ports.

Add a flag to specify a vlan bridge binding mode, by which the link
state is no longer automatically transferred from the lower device,
but is instead determined by the bridge ports that are members of the
vlan.

Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
---
 include/uapi/linux/if_vlan.h | 9 +++++----
 net/8021q/vlan_dev.c         | 3 ++-
 net/8021q/vlan_netlink.c     | 3 ++-
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/include/uapi/linux/if_vlan.h b/include/uapi/linux/if_vlan.h
index 7a0e8bd65b6b..601931ac8002 100644
--- a/include/uapi/linux/if_vlan.h
+++ b/include/uapi/linux/if_vlan.h
@@ -32,10 +32,11 @@ enum vlan_ioctl_cmds {
 };
 
 enum vlan_flags {
-	VLAN_FLAG_REORDER_HDR	= 0x1,
-	VLAN_FLAG_GVRP		= 0x2,
-	VLAN_FLAG_LOOSE_BINDING	= 0x4,
-	VLAN_FLAG_MVRP		= 0x8,
+	VLAN_FLAG_REORDER_HDR		= 0x1,
+	VLAN_FLAG_GVRP			= 0x2,
+	VLAN_FLAG_LOOSE_BINDING		= 0x4,
+	VLAN_FLAG_MVRP			= 0x8,
+	VLAN_FLAG_BRIDGE_BINDING	= 0x16,
 };
 
 enum vlan_name_types {
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 15293c2a5dd8..86b38bb87f9a 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -223,7 +223,8 @@ int vlan_dev_change_flags(const struct net_device *dev, u32 flags, u32 mask)
 	u32 old_flags = vlan->flags;
 
 	if (mask & ~(VLAN_FLAG_REORDER_HDR | VLAN_FLAG_GVRP |
-		     VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP))
+		     VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP |
+		     VLAN_FLAG_BRIDGE_BINDING))
 		return -EINVAL;
 
 	vlan->flags = (old_flags & ~mask) | (flags & mask);
diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
index 9b60c1e399e2..a624dccf68fd 100644
--- a/net/8021q/vlan_netlink.c
+++ b/net/8021q/vlan_netlink.c
@@ -84,7 +84,8 @@ static int vlan_validate(struct nlattr *tb[], struct nlattr *data[],
 		flags = nla_data(data[IFLA_VLAN_FLAGS]);
 		if ((flags->flags & flags->mask) &
 		    ~(VLAN_FLAG_REORDER_HDR | VLAN_FLAG_GVRP |
-		      VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP)) {
+		      VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP |
+		      VLAN_FLAG_BRIDGE_BINDING)) {
 			NL_SET_ERR_MSG_MOD(extack, "Invalid VLAN flags");
 			return -EINVAL;
 		}
-- 
2.11.0

Re: [PATCH net-next 1/4] vlan: support binding link state to vlan member bridge ports

[Nikolay Aleksandrov]

On 02/04/2019 18:35, Mike Manning wrote:
> In the case of vlan filtering on bridges, the bridge may also have the
> corresponding vlan devices as upper devices. Currently the link state
> of vlan devices is transferred from the lower device. So this is up if
> the bridge is in admin up state and there is at least one bridge port
> that is up, regardless of the vlan that the port is a member of.
> 
> The link state of the vlan device may need to track only the state of
> the subset of ports that are also members of the corresponding vlan,
> rather than that of all ports.
> 
> Add a flag to specify a vlan bridge binding mode, by which the link
> state is no longer automatically transferred from the lower device,
> but is instead determined by the bridge ports that are members of the
> vlan.
> 
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
>  include/uapi/linux/if_vlan.h | 9 +++++----
>  net/8021q/vlan_dev.c         | 3 ++-
>  net/8021q/vlan_netlink.c     | 3 ++-
>  3 files changed, 9 insertions(+), 6 deletions(-)
> 

What if the following happens:
1. add binding vlan X on bridge
2. no up vlan ports for X
3. set no carrier on vlan X
4. remove binding flag on X 

Would vlan X remain in no carrier state ?

> diff --git a/include/uapi/linux/if_vlan.h b/include/uapi/linux/if_vlan.h
> index 7a0e8bd65b6b..601931ac8002 100644
> --- a/include/uapi/linux/if_vlan.h
> +++ b/include/uapi/linux/if_vlan.h
> @@ -32,10 +32,11 @@ enum vlan_ioctl_cmds {
>  };
>  
>  enum vlan_flags {
> -	VLAN_FLAG_REORDER_HDR	= 0x1,
> -	VLAN_FLAG_GVRP		= 0x2,
> -	VLAN_FLAG_LOOSE_BINDING	= 0x4,
> -	VLAN_FLAG_MVRP		= 0x8,
> +	VLAN_FLAG_REORDER_HDR		= 0x1,
> +	VLAN_FLAG_GVRP			= 0x2,
> +	VLAN_FLAG_LOOSE_BINDING		= 0x4,
> +	VLAN_FLAG_MVRP			= 0x8,
> +	VLAN_FLAG_BRIDGE_BINDING	= 0x16,
>  };
>  
>  enum vlan_name_types {
> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> index 15293c2a5dd8..86b38bb87f9a 100644
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -223,7 +223,8 @@ int vlan_dev_change_flags(const struct net_device *dev, u32 flags, u32 mask)
>  	u32 old_flags = vlan->flags;
>  
>  	if (mask & ~(VLAN_FLAG_REORDER_HDR | VLAN_FLAG_GVRP |
> -		     VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP))
> +		     VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP |
> +		     VLAN_FLAG_BRIDGE_BINDING))
>  		return -EINVAL;
>  
>  	vlan->flags = (old_flags & ~mask) | (flags & mask);
> diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
> index 9b60c1e399e2..a624dccf68fd 100644
> --- a/net/8021q/vlan_netlink.c
> +++ b/net/8021q/vlan_netlink.c
> @@ -84,7 +84,8 @@ static int vlan_validate(struct nlattr *tb[], struct nlattr *data[],
>  		flags = nla_data(data[IFLA_VLAN_FLAGS]);
>  		if ((flags->flags & flags->mask) &
>  		    ~(VLAN_FLAG_REORDER_HDR | VLAN_FLAG_GVRP |
> -		      VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP)) {
> +		      VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP |
> +		      VLAN_FLAG_BRIDGE_BINDING)) {
>  			NL_SET_ERR_MSG_MOD(extack, "Invalid VLAN flags");
>  			return -EINVAL;
>  		}
> 

Re: [PATCH net-next 1/4] vlan: support binding link state to vlan member bridge ports

[Nikolay Aleksandrov]

On 02/04/2019 22:20, Nikolay Aleksandrov wrote:
> On 02/04/2019 18:35, Mike Manning wrote:
>> In the case of vlan filtering on bridges, the bridge may also have the
>> corresponding vlan devices as upper devices. Currently the link state
>> of vlan devices is transferred from the lower device. So this is up if
>> the bridge is in admin up state and there is at least one bridge port
>> that is up, regardless of the vlan that the port is a member of.
>>
>> The link state of the vlan device may need to track only the state of
>> the subset of ports that are also members of the corresponding vlan,
>> rather than that of all ports.
>>
>> Add a flag to specify a vlan bridge binding mode, by which the link
>> state is no longer automatically transferred from the lower device,
>> but is instead determined by the bridge ports that are members of the
>> vlan.
>>
>> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
>> ---
>>  include/uapi/linux/if_vlan.h | 9 +++++----
>>  net/8021q/vlan_dev.c         | 3 ++-
>>  net/8021q/vlan_netlink.c     | 3 ++-
>>  3 files changed, 9 insertions(+), 6 deletions(-)
>>
> 
> What if the following happens:
> 1. add binding vlan X on bridge
> 2. no up vlan ports for X
> 3. set no carrier on vlan X
> 4. remove binding flag on X 
> 
> Would vlan X remain in no carrier state ?
> 

Ah patch 02 arrived much later, I think this should be fine. :)

>> diff --git a/include/uapi/linux/if_vlan.h b/include/uapi/linux/if_vlan.h
>> index 7a0e8bd65b6b..601931ac8002 100644
>> --- a/include/uapi/linux/if_vlan.h
>> +++ b/include/uapi/linux/if_vlan.h
>> @@ -32,10 +32,11 @@ enum vlan_ioctl_cmds {
>>  };
>>  
>>  enum vlan_flags {
>> -	VLAN_FLAG_REORDER_HDR	= 0x1,
>> -	VLAN_FLAG_GVRP		= 0x2,
>> -	VLAN_FLAG_LOOSE_BINDING	= 0x4,
>> -	VLAN_FLAG_MVRP		= 0x8,
>> +	VLAN_FLAG_REORDER_HDR		= 0x1,
>> +	VLAN_FLAG_GVRP			= 0x2,
>> +	VLAN_FLAG_LOOSE_BINDING		= 0x4,
>> +	VLAN_FLAG_MVRP			= 0x8,
>> +	VLAN_FLAG_BRIDGE_BINDING	= 0x16,
>>  };
>>  
>>  enum vlan_name_types {
>> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
>> index 15293c2a5dd8..86b38bb87f9a 100644
>> --- a/net/8021q/vlan_dev.c
>> +++ b/net/8021q/vlan_dev.c
>> @@ -223,7 +223,8 @@ int vlan_dev_change_flags(const struct net_device *dev, u32 flags, u32 mask)
>>  	u32 old_flags = vlan->flags;
>>  
>>  	if (mask & ~(VLAN_FLAG_REORDER_HDR | VLAN_FLAG_GVRP |
>> -		     VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP))
>> +		     VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP |
>> +		     VLAN_FLAG_BRIDGE_BINDING))
>>  		return -EINVAL;
>>  
>>  	vlan->flags = (old_flags & ~mask) | (flags & mask);
>> diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c
>> index 9b60c1e399e2..a624dccf68fd 100644
>> --- a/net/8021q/vlan_netlink.c
>> +++ b/net/8021q/vlan_netlink.c
>> @@ -84,7 +84,8 @@ static int vlan_validate(struct nlattr *tb[], struct nlattr *data[],
>>  		flags = nla_data(data[IFLA_VLAN_FLAGS]);
>>  		if ((flags->flags & flags->mask) &
>>  		    ~(VLAN_FLAG_REORDER_HDR | VLAN_FLAG_GVRP |
>> -		      VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP)) {
>> +		      VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP |
>> +		      VLAN_FLAG_BRIDGE_BINDING)) {
>>  			NL_SET_ERR_MSG_MOD(extack, "Invalid VLAN flags");
>>  			return -EINVAL;
>>  		}
>>
> 

[PATCH net-next 2/4] vlan: do not transfer link state in vlan bridge binding mode

[Mike Manning]

In vlan bridge binding mode, the link state is no longer transferred
from the lower device. Instead it is set by the bridge module according
to the state of bridge ports that are members of the vlan.

Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
---
 net/8021q/vlan.c     | 18 ++++++++++++++----
 net/8021q/vlan_dev.c | 19 ++++++++++++-------
 2 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index dc4411165e43..1f99678751df 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -75,6 +75,14 @@ static int vlan_group_prealloc_vid(struct vlan_group *vg,
 	return 0;
 }
 
+static void vlan_stacked_transfer_operstate(const struct net_device *rootdev,
+					    struct net_device *dev,
+					    struct vlan_dev_priv *vlan)
+{
+	if (!(vlan->flags & VLAN_FLAG_BRIDGE_BINDING))
+		netif_stacked_transfer_operstate(rootdev, dev);
+}
+
 void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
 {
 	struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
@@ -180,7 +188,7 @@ int register_vlan_dev(struct net_device *dev, struct netlink_ext_ack *extack)
 	/* Account for reference in struct vlan_dev_priv */
 	dev_hold(real_dev);
 
-	netif_stacked_transfer_operstate(real_dev, dev);
+	vlan_stacked_transfer_operstate(real_dev, dev, vlan);
 	linkwatch_fire_event(dev); /* _MUST_ call rfc2863_policy() */
 
 	/* So, got the sucker initialized, now lets place
@@ -399,7 +407,8 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
 	case NETDEV_CHANGE:
 		/* Propagate real device state to vlan devices */
 		vlan_group_for_each_dev(grp, i, vlandev)
-			netif_stacked_transfer_operstate(dev, vlandev);
+			vlan_stacked_transfer_operstate(dev, vlandev,
+							vlan_dev_priv(vlandev));
 		break;
 
 	case NETDEV_CHANGEADDR:
@@ -446,7 +455,8 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
 		dev_close_many(&close_list, false);
 
 		list_for_each_entry_safe(vlandev, tmp, &close_list, close_list) {
-			netif_stacked_transfer_operstate(dev, vlandev);
+			vlan_stacked_transfer_operstate(dev, vlandev,
+							vlan_dev_priv(vlandev));
 			list_del_init(&vlandev->close_list);
 		}
 		list_del(&close_list);
@@ -463,7 +473,7 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
 			if (!(vlan->flags & VLAN_FLAG_LOOSE_BINDING))
 				dev_change_flags(vlandev, flgs | IFF_UP,
 						 extack);
-			netif_stacked_transfer_operstate(dev, vlandev);
+			vlan_stacked_transfer_operstate(dev, vlandev, vlan);
 		}
 		break;
 
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 86b38bb87f9a..270df9f0dfea 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -297,7 +297,8 @@ static int vlan_dev_open(struct net_device *dev)
 	if (vlan->flags & VLAN_FLAG_MVRP)
 		vlan_mvrp_request_join(dev);
 
-	if (netif_carrier_ok(real_dev))
+	if (netif_carrier_ok(real_dev) &&
+	    !(vlan->flags & VLAN_FLAG_BRIDGE_BINDING))
 		netif_carrier_on(dev);
 	return 0;
 
@@ -327,7 +328,8 @@ static int vlan_dev_stop(struct net_device *dev)
 	if (!ether_addr_equal(dev->dev_addr, real_dev->dev_addr))
 		dev_uc_del(real_dev, dev->dev_addr);
 
-	netif_carrier_off(dev);
+	if (!(vlan->flags & VLAN_FLAG_BRIDGE_BINDING))
+		netif_carrier_off(dev);
 	return 0;
 }
 
@@ -549,7 +551,8 @@ static const struct net_device_ops vlan_netdev_ops;
 
 static int vlan_dev_init(struct net_device *dev)
 {
-	struct net_device *real_dev = vlan_dev_priv(dev)->real_dev;
+	struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
+	struct net_device *real_dev = vlan->real_dev;
 
 	netif_carrier_off(dev);
 
@@ -560,6 +563,9 @@ static int vlan_dev_init(struct net_device *dev)
 					  (1<<__LINK_STATE_DORMANT))) |
 		      (1<<__LINK_STATE_PRESENT);
 
+	if (vlan->flags & VLAN_FLAG_BRIDGE_BINDING)
+		dev->state |= (1 << __LINK_STATE_NOCARRIER);
+
 	dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
 			   NETIF_F_FRAGLIST | NETIF_F_GSO_SOFTWARE |
 			   NETIF_F_GSO_ENCAP_ALL |
@@ -590,8 +596,7 @@ static int vlan_dev_init(struct net_device *dev)
 #endif
 
 	dev->needed_headroom = real_dev->needed_headroom;
-	if (vlan_hw_offload_capable(real_dev->features,
-				    vlan_dev_priv(dev)->vlan_proto)) {
+	if (vlan_hw_offload_capable(real_dev->features, vlan->vlan_proto)) {
 		dev->header_ops      = &vlan_passthru_header_ops;
 		dev->hard_header_len = real_dev->hard_header_len;
 	} else {
@@ -605,8 +610,8 @@ static int vlan_dev_init(struct net_device *dev)
 
 	vlan_dev_set_lockdep_class(dev, vlan_dev_get_lock_subclass(dev));
 
-	vlan_dev_priv(dev)->vlan_pcpu_stats = netdev_alloc_pcpu_stats(struct vlan_pcpu_stats);
-	if (!vlan_dev_priv(dev)->vlan_pcpu_stats)
+	vlan->vlan_pcpu_stats = netdev_alloc_pcpu_stats(struct vlan_pcpu_stats);
+	if (!vlan->vlan_pcpu_stats)
 		return -ENOMEM;
 
 	return 0;
-- 
2.11.0

Re: [PATCH net-next 2/4] vlan: do not transfer link state in vlan bridge binding mode

[Nikolay Aleksandrov]

On 02/04/2019 18:35, Mike Manning wrote:
> In vlan bridge binding mode, the link state is no longer transferred
> from the lower device. Instead it is set by the bridge module according
> to the state of bridge ports that are members of the vlan.
> 
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
>  net/8021q/vlan.c     | 18 ++++++++++++++----
>  net/8021q/vlan_dev.c | 19 ++++++++++++-------
>  2 files changed, 26 insertions(+), 11 deletions(-)
> 
> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
> index dc4411165e43..1f99678751df 100644
> --- a/net/8021q/vlan.c
> +++ b/net/8021q/vlan.c
> @@ -75,6 +75,14 @@ static int vlan_group_prealloc_vid(struct vlan_group *vg,
>  	return 0;
>  }
>  
> +static void vlan_stacked_transfer_operstate(const struct net_device *rootdev,
> +					    struct net_device *dev,
> +					    struct vlan_dev_priv *vlan)
> +{
> +	if (!(vlan->flags & VLAN_FLAG_BRIDGE_BINDING))
> +		netif_stacked_transfer_operstate(rootdev, dev);
> +}

I think this may be problematic with STP since STP can set netif_carrier_off() to
the bridge device even with up ports (but not forwarding) and it will not be propagated
to the vlan

> +
>  void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
>  {
>  	struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
> @@ -180,7 +188,7 @@ int register_vlan_dev(struct net_device *dev, struct netlink_ext_ack *extack)
>  	/* Account for reference in struct vlan_dev_priv */
>  	dev_hold(real_dev);
>  
> -	netif_stacked_transfer_operstate(real_dev, dev);
> +	vlan_stacked_transfer_operstate(real_dev, dev, vlan);
>  	linkwatch_fire_event(dev); /* _MUST_ call rfc2863_policy() */
>  
>  	/* So, got the sucker initialized, now lets place
> @@ -399,7 +407,8 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
>  	case NETDEV_CHANGE:
>  		/* Propagate real device state to vlan devices */
>  		vlan_group_for_each_dev(grp, i, vlandev)
> -			netif_stacked_transfer_operstate(dev, vlandev);
> +			vlan_stacked_transfer_operstate(dev, vlandev,
> +							vlan_dev_priv(vlandev));
>  		break;
>  
>  	case NETDEV_CHANGEADDR:
> @@ -446,7 +455,8 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
>  		dev_close_many(&close_list, false);
>  
>  		list_for_each_entry_safe(vlandev, tmp, &close_list, close_list) {
> -			netif_stacked_transfer_operstate(dev, vlandev);
> +			vlan_stacked_transfer_operstate(dev, vlandev,
> +							vlan_dev_priv(vlandev));
>  			list_del_init(&vlandev->close_list);
>  		}
>  		list_del(&close_list);
> @@ -463,7 +473,7 @@ static int vlan_device_event(struct notifier_block *unused, unsigned long event,
>  			if (!(vlan->flags & VLAN_FLAG_LOOSE_BINDING))
>  				dev_change_flags(vlandev, flgs | IFF_UP,
>  						 extack);
> -			netif_stacked_transfer_operstate(dev, vlandev);
> +			vlan_stacked_transfer_operstate(dev, vlandev, vlan);
>  		}
>  		break;
>  
> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
> index 86b38bb87f9a..270df9f0dfea 100644
> --- a/net/8021q/vlan_dev.c
> +++ b/net/8021q/vlan_dev.c
> @@ -297,7 +297,8 @@ static int vlan_dev_open(struct net_device *dev)
>  	if (vlan->flags & VLAN_FLAG_MVRP)
>  		vlan_mvrp_request_join(dev);
>  
> -	if (netif_carrier_ok(real_dev))
> +	if (netif_carrier_ok(real_dev) &&
> +	    !(vlan->flags & VLAN_FLAG_BRIDGE_BINDING))
>  		netif_carrier_on(dev);
>  	return 0;
>  
> @@ -327,7 +328,8 @@ static int vlan_dev_stop(struct net_device *dev)
>  	if (!ether_addr_equal(dev->dev_addr, real_dev->dev_addr))
>  		dev_uc_del(real_dev, dev->dev_addr);
>  
> -	netif_carrier_off(dev);
> +	if (!(vlan->flags & VLAN_FLAG_BRIDGE_BINDING))
> +		netif_carrier_off(dev);
>  	return 0;
>  }
>  
> @@ -549,7 +551,8 @@ static const struct net_device_ops vlan_netdev_ops;
>  
>  static int vlan_dev_init(struct net_device *dev)
>  {
> -	struct net_device *real_dev = vlan_dev_priv(dev)->real_dev;
> +	struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
> +	struct net_device *real_dev = vlan->real_dev;
>  
>  	netif_carrier_off(dev);
>  
> @@ -560,6 +563,9 @@ static int vlan_dev_init(struct net_device *dev)
>  					  (1<<__LINK_STATE_DORMANT))) |
>  		      (1<<__LINK_STATE_PRESENT);
>  
> +	if (vlan->flags & VLAN_FLAG_BRIDGE_BINDING)
> +		dev->state |= (1 << __LINK_STATE_NOCARRIER);
> +
>  	dev->hw_features = NETIF_F_HW_CSUM | NETIF_F_SG |
>  			   NETIF_F_FRAGLIST | NETIF_F_GSO_SOFTWARE |
>  			   NETIF_F_GSO_ENCAP_ALL |
> @@ -590,8 +596,7 @@ static int vlan_dev_init(struct net_device *dev)
>  #endif
>  
>  	dev->needed_headroom = real_dev->needed_headroom;
> -	if (vlan_hw_offload_capable(real_dev->features,
> -				    vlan_dev_priv(dev)->vlan_proto)) {
> +	if (vlan_hw_offload_capable(real_dev->features, vlan->vlan_proto)) {
>  		dev->header_ops      = &vlan_passthru_header_ops;
>  		dev->hard_header_len = real_dev->hard_header_len;
>  	} else {
> @@ -605,8 +610,8 @@ static int vlan_dev_init(struct net_device *dev)
>  
>  	vlan_dev_set_lockdep_class(dev, vlan_dev_get_lock_subclass(dev));
>  
> -	vlan_dev_priv(dev)->vlan_pcpu_stats = netdev_alloc_pcpu_stats(struct vlan_pcpu_stats);
> -	if (!vlan_dev_priv(dev)->vlan_pcpu_stats)
> +	vlan->vlan_pcpu_stats = netdev_alloc_pcpu_stats(struct vlan_pcpu_stats);
> +	if (!vlan->vlan_pcpu_stats)
>  		return -ENOMEM;
>  
>  	return 0;
> 

Re: [PATCH net-next 2/4] vlan: do not transfer link state in vlan bridge binding mode

[Mike Manning]

On 02/04/2019 21:15, Nikolay Aleksandrov wrote:
> On 02/04/2019 18:35, Mike Manning wrote:
>> In vlan bridge binding mode, the link state is no longer transferred
>> from the lower device. Instead it is set by the bridge module according
>> to the state of bridge ports that are members of the vlan.
>>
>> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
>> ---
>>  net/8021q/vlan.c     | 18 ++++++++++++++----
>>  net/8021q/vlan_dev.c | 19 ++++++++++++-------
>>  2 files changed, 26 insertions(+), 11 deletions(-)
>>
>> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
>> index dc4411165e43..1f99678751df 100644
>> --- a/net/8021q/vlan.c
>> +++ b/net/8021q/vlan.c
>> @@ -75,6 +75,14 @@ static int vlan_group_prealloc_vid(struct vlan_group *vg,
>>  	return 0;
>>  }
>>  
>> +static void vlan_stacked_transfer_operstate(const struct net_device *rootdev,
>> +					    struct net_device *dev,
>> +					    struct vlan_dev_priv *vlan)
>> +{
>> +	if (!(vlan->flags & VLAN_FLAG_BRIDGE_BINDING))
>> +		netif_stacked_transfer_operstate(rootdev, dev);
>> +}
> I think this may be problematic with STP since STP can set netif_carrier_off() to
> the bridge device even with up ports (but not forwarding) and it will not be propagated
> to the vlan
>
Thanks for catching this issue, I will need to work on a solution for
this before submitting a v1 series (if at all possible). We do not have
this concern with the specific topology for which these changes are
required, but carrier changes due to STP must propagate even with this
option.

[PATCH net-next 3/4] bridge: support binding vlan dev link state to vlan member bridge ports

[Mike Manning]

In the case of vlan filtering on bridges, the bridge may also have the
corresponding vlan devices as upper devices. A vlan bridge binding mode
is added to allow the link state of the vlan device to track only the
state of the subset of bridge ports that are also members of the vlan,
rather than that of all bridge ports. This mode is set with a vlan flag
rather than a bridge sysfs so that the 8021q module is aware that it
should not set the link state for the vlan device.

If bridge vlan is configured, the bridge device event handling results
in the link state for an upper device being set, if it is a vlan device
with the vlan bridge binding mode enabled. This also sets a
vlan_bridge_binding flag so that subsequent UP/DOWN/CHANGE events for
the ports in that bridge result in a link state update of the vlan
device if required.

The link state of the vlan device is up if there is at least one bridge
port that is a vlan member that is admin & oper up, otherwise its oper
state is IF_OPER_LOWERLAYERDOWN.

Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
---
 net/bridge/br.c         |  23 ++++++--
 net/bridge/br_private.h |  17 ++++++
 net/bridge/br_vlan.c    | 143 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 179 insertions(+), 4 deletions(-)

diff --git a/net/bridge/br.c b/net/bridge/br.c
index a5174e5001d8..b80cd5ccd590 100644
--- a/net/bridge/br.c
+++ b/net/bridge/br.c
@@ -40,10 +40,21 @@ static int br_device_event(struct notifier_block *unused, unsigned long event, v
 	bool changed_addr;
 	int err;
 
-	/* register of bridge completed, add sysfs entries */
-	if ((dev->priv_flags & IFF_EBRIDGE) && event == NETDEV_REGISTER) {
-		br_sysfs_addbr(dev);
-		return NOTIFY_DONE;
+	if (dev->priv_flags & IFF_EBRIDGE) {
+		if (event == NETDEV_REGISTER) {
+			/* register of bridge completed, add sysfs entries */
+			br_sysfs_addbr(dev);
+			return NOTIFY_DONE;
+		}
+#ifdef CONFIG_BRIDGE_VLAN_FILTERING
+		if (event == NETDEV_CHANGEUPPER) {
+			struct netdev_notifier_changeupper_info *info = ptr;
+
+			br_vlan_upper_change(dev, info->upper_dev,
+					     info->linking);
+			return NOTIFY_DONE;
+		}
+#endif
 	}
 
 	/* not a port of a bridge */
@@ -126,6 +137,10 @@ static int br_device_event(struct notifier_block *unused, unsigned long event, v
 		break;
 	}
 
+#ifdef CONFIG_BRIDGE_VLAN_FILTERING
+	br_vlan_port_event(p, br, event);
+#endif
+
 	/* Events that may cause spanning tree to refresh */
 	if (!notified && (event == NETDEV_CHANGEADDR || event == NETDEV_UP ||
 			  event == NETDEV_CHANGE || event == NETDEV_DOWN))
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 00deef7fc1f3..604de174abe0 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -336,6 +336,7 @@ struct net_bridge {
 #ifdef CONFIG_BRIDGE_VLAN_FILTERING
 	__be16				vlan_proto;
 	u16				default_pvid;
+	u8				vlan_bridge_binding;
 	struct net_bridge_vlan_group	__rcu *vlgrp;
 #endif
 
@@ -896,6 +897,10 @@ int nbp_vlan_init(struct net_bridge_port *port, struct netlink_ext_ack *extack);
 int nbp_get_num_vlan_infos(struct net_bridge_port *p, u32 filter_mask);
 void br_vlan_get_stats(const struct net_bridge_vlan *v,
 		       struct br_vlan_stats *stats);
+void br_vlan_port_event(struct net_bridge_port *p, struct net_bridge *br,
+			unsigned long event);
+void br_vlan_upper_change(struct net_device *dev, struct net_device *upper_dev,
+			  bool linking);
 
 static inline struct net_bridge_vlan_group *br_vlan_group(
 					const struct net_bridge *br)
@@ -1079,6 +1084,18 @@ static inline void br_vlan_get_stats(const struct net_bridge_vlan *v,
 				     struct br_vlan_stats *stats)
 {
 }
+
+static inline void br_vlan_port_event(struct net_bridge_port *p,
+				      struct net_bridge *br,
+				      unsigned long event)
+{
+}
+
+static inline void br_vlan_upper_change(struct net_device *dev,
+					struct net_device *upper_dev,
+					bool linking)
+{
+}
 #endif
 
 struct nf_br_ops {
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 96abf8feb9dc..642373231386 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -1265,3 +1265,146 @@ int br_vlan_get_info(const struct net_device *dev, u16 vid,
 	return 0;
 }
 EXPORT_SYMBOL_GPL(br_vlan_get_info);
+
+static int br_vlan_is_bind_vlan_dev(struct net_device *dev)
+{
+	return is_vlan_dev(dev) &&
+		!!(vlan_dev_priv(dev)->flags & VLAN_FLAG_BRIDGE_BINDING);
+}
+
+static int br_vlan_is_bind_vlan_dev_fn(struct net_device *dev,
+				       __always_unused void *data)
+{
+	return br_vlan_is_bind_vlan_dev(dev);
+}
+
+static int br_vlan_has_upper_bind_vlan_dev(struct net_device *dev)
+{
+	int found;
+
+	rcu_read_lock();
+	found = netdev_walk_all_upper_dev_rcu(dev, br_vlan_is_bind_vlan_dev_fn,
+					      NULL);
+	rcu_read_unlock();
+
+	return found;
+}
+
+struct br_vlan_bind_walk_data {
+	u16 vid;
+	struct net_device *result;
+};
+
+static int br_vlan_match_bind_vlan_dev_fn(struct net_device *dev, void *data_in)
+{
+	struct br_vlan_bind_walk_data *data = data_in;
+	int found = 0;
+
+	if (br_vlan_is_bind_vlan_dev(dev) &&
+	    vlan_dev_priv(dev)->vlan_id == data->vid) {
+		dev_hold(dev);
+		data->result = dev;
+		found = 1;
+	}
+
+	return found;
+}
+
+/* If found, returns the vlan device with a reference held, else returns NULL.
+ */
+static struct net_device *
+br_vlan_get_upper_bind_vlan_dev(struct net_device *dev, u16 vid)
+{
+	struct br_vlan_bind_walk_data data = {
+		.vid = vid,
+	};
+
+	rcu_read_lock();
+	netdev_walk_all_upper_dev_rcu(dev, br_vlan_match_bind_vlan_dev_fn,
+				      &data);
+	rcu_read_unlock();
+
+	return data.result;
+}
+
+static bool br_vlan_is_dev_up(struct net_device *dev)
+{
+	return  !!(dev->flags & IFF_UP) && netif_oper_up(dev);
+}
+
+static void br_vlan_set_vlan_dev_state(struct net_bridge *br,
+				       struct net_device *vlan_dev)
+{
+	u16 vid = vlan_dev_priv(vlan_dev)->vlan_id;
+	struct net_bridge_vlan_group *vg;
+	struct net_bridge_port *p;
+	bool has_carrier = false;
+
+	list_for_each_entry(p, &br->port_list, list) {
+		vg = nbp_vlan_group(p);
+		if (br_vlan_find(vg, vid) && br_vlan_is_dev_up(p->dev)) {
+			has_carrier = true;
+			break;
+		}
+	}
+
+	if (netif_carrier_ok(vlan_dev)) {
+		if (!has_carrier)
+			netif_carrier_off(vlan_dev);
+	} else {
+		if (has_carrier)
+			netif_carrier_on(vlan_dev);
+	}
+}
+
+static void br_vlan_set_all_vlan_dev_state(struct net_bridge_port *p,
+					   struct net_bridge *br)
+{
+	struct net_bridge_vlan_group *vg = nbp_vlan_group(p);
+	struct net_bridge_vlan *vlan;
+	struct net_device *vlan_dev;
+
+	list_for_each_entry(vlan, &vg->vlan_list, vlist) {
+		vlan_dev = br_vlan_get_upper_bind_vlan_dev(br->dev, vlan->vid);
+		if (vlan_dev) {
+			if (br_vlan_is_dev_up(p->dev)) {
+				if (!netif_carrier_ok(vlan_dev))
+					netif_carrier_on(vlan_dev);
+			} else {
+				br_vlan_set_vlan_dev_state(br, vlan_dev);
+			}
+			dev_put(vlan_dev);
+		}
+	}
+}
+
+void br_vlan_upper_change(struct net_device *dev, struct net_device *upper_dev,
+			  bool linking)
+{
+	struct net_bridge *br = netdev_priv(dev);
+
+	if (!br_vlan_is_bind_vlan_dev(upper_dev))
+		return;
+
+	if (linking) {
+		br_vlan_set_vlan_dev_state(br, upper_dev);
+		br->vlan_bridge_binding = 1;
+	} else {
+		br->vlan_bridge_binding = br_vlan_has_upper_bind_vlan_dev(dev);
+	}
+}
+
+void br_vlan_port_event(struct net_bridge_port *p, struct net_bridge *br,
+			unsigned long event)
+{
+	if (!br->vlan_bridge_binding)
+		return;
+
+	switch (event) {
+	case NETDEV_CHANGE:
+	case NETDEV_DOWN:
+	case NETDEV_UP:
+		br_vlan_set_all_vlan_dev_state(p, br);
+		break;
+	}
+}
-- 
2.11.0

Re: [PATCH net-next 3/4] bridge: support binding vlan dev link state to vlan member bridge ports

[Nikolay Aleksandrov]

On 02/04/2019 18:35, Mike Manning wrote:
> In the case of vlan filtering on bridges, the bridge may also have the
> corresponding vlan devices as upper devices. A vlan bridge binding mode
> is added to allow the link state of the vlan device to track only the
> state of the subset of bridge ports that are also members of the vlan,
> rather than that of all bridge ports. This mode is set with a vlan flag
> rather than a bridge sysfs so that the 8021q module is aware that it
> should not set the link state for the vlan device.
> 
> If bridge vlan is configured, the bridge device event handling results
> in the link state for an upper device being set, if it is a vlan device
> with the vlan bridge binding mode enabled. This also sets a
> vlan_bridge_binding flag so that subsequent UP/DOWN/CHANGE events for
> the ports in that bridge result in a link state update of the vlan
> device if required.
> 
> The link state of the vlan device is up if there is at least one bridge
> port that is a vlan member that is admin & oper up, otherwise its oper
> state is IF_OPER_LOWERLAYERDOWN.
> 
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
>  net/bridge/br.c         |  23 ++++++--
>  net/bridge/br_private.h |  17 ++++++
>  net/bridge/br_vlan.c    | 143 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 179 insertions(+), 4 deletions(-)
> 

Hi,
Please CC bridge maintainers when sending bridge patches.
One question/thought - can't we add a ports_up counter in the vlan's master
struct and keep how many ports are up for that vlan ?
The important part would be to keep it correct, i.e. vlan_add/del should inc/dec
as well as port up/down. Then we can directly update its carrier on port event
without doing a possible O(n^2) walk, we just need to walk over the port vlans
and adjust counters which is always O(n) based on num of that port's vlans.

Some more comments below.


> diff --git a/net/bridge/br.c b/net/bridge/br.c
> index a5174e5001d8..b80cd5ccd590 100644
> --- a/net/bridge/br.c
> +++ b/net/bridge/br.c
> @@ -40,10 +40,21 @@ static int br_device_event(struct notifier_block *unused, unsigned long event, v
>  	bool changed_addr;
>  	int err;
>  
> -	/* register of bridge completed, add sysfs entries */
> -	if ((dev->priv_flags & IFF_EBRIDGE) && event == NETDEV_REGISTER) {
> -		br_sysfs_addbr(dev);
> -		return NOTIFY_DONE;
> +	if (dev->priv_flags & IFF_EBRIDGE) {
> +		if (event == NETDEV_REGISTER) {
> +			/* register of bridge completed, add sysfs entries */
> +			br_sysfs_addbr(dev);
> +			return NOTIFY_DONE;
> +		}
> +#ifdef CONFIG_BRIDGE_VLAN_FILTERING
> +		if (event == NETDEV_CHANGEUPPER) {
> +			struct netdev_notifier_changeupper_info *info = ptr;
> +
> +			br_vlan_upper_change(dev, info->upper_dev,
> +					     info->linking);
> +			return NOTIFY_DONE;
> +		}
> +#endif
>  	}
>  
>  	/* not a port of a bridge */
> @@ -126,6 +137,10 @@ static int br_device_event(struct notifier_block *unused, unsigned long event, v
>  		break;
>  	}
>  
> +#ifdef CONFIG_BRIDGE_VLAN_FILTERING
> +	br_vlan_port_event(p, br, event);
> +#endif
> +
>  	/* Events that may cause spanning tree to refresh */
>  	if (!notified && (event == NETDEV_CHANGEADDR || event == NETDEV_UP ||
>  			  event == NETDEV_CHANGE || event == NETDEV_DOWN))
> diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
> index 00deef7fc1f3..604de174abe0 100644
> --- a/net/bridge/br_private.h
> +++ b/net/bridge/br_private.h
> @@ -336,6 +336,7 @@ struct net_bridge {
>  #ifdef CONFIG_BRIDGE_VLAN_FILTERING
>  	__be16				vlan_proto;
>  	u16				default_pvid;
> +	u8				vlan_bridge_binding;

Use the bridge private bit options for this, don't add new fields. Take a look
at the br_opt_get/br_opt_toggle and the BROPT_ options.

>  	struct net_bridge_vlan_group	__rcu *vlgrp;
>  #endif
>  
> @@ -896,6 +897,10 @@ int nbp_vlan_init(struct net_bridge_port *port, struct netlink_ext_ack *extack);
>  int nbp_get_num_vlan_infos(struct net_bridge_port *p, u32 filter_mask);
>  void br_vlan_get_stats(const struct net_bridge_vlan *v,
>  		       struct br_vlan_stats *stats);
> +void br_vlan_port_event(struct net_bridge_port *p, struct net_bridge *br,
> +			unsigned long event);
> +void br_vlan_upper_change(struct net_device *dev, struct net_device *upper_dev,
> +			  bool linking);
>  
>  static inline struct net_bridge_vlan_group *br_vlan_group(
>  					const struct net_bridge *br)
> @@ -1079,6 +1084,18 @@ static inline void br_vlan_get_stats(const struct net_bridge_vlan *v,
>  				     struct br_vlan_stats *stats)
>  {
>  }
> +
> +static inline void br_vlan_port_event(struct net_bridge_port *p,
> +				      struct net_bridge *br,
> +				      unsigned long event)
> +{
> +}
> +
> +static inline void br_vlan_upper_change(struct net_device *dev,
> +					struct net_device *upper_dev,
> +					bool linking)
> +{
> +}
>  #endif
>  
>  struct nf_br_ops {
> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> index 96abf8feb9dc..642373231386 100644
> --- a/net/bridge/br_vlan.c
> +++ b/net/bridge/br_vlan.c
> @@ -1265,3 +1265,146 @@ int br_vlan_get_info(const struct net_device *dev, u16 vid,
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(br_vlan_get_info);
> +
> +static int br_vlan_is_bind_vlan_dev(struct net_device *dev)

const dev

> +{
> +	return is_vlan_dev(dev) &&
> +		!!(vlan_dev_priv(dev)->flags & VLAN_FLAG_BRIDGE_BINDING);
> +}
> +
> +static int br_vlan_is_bind_vlan_dev_fn(struct net_device *dev,
> +				       __always_unused void *data)
> +{
> +	return br_vlan_is_bind_vlan_dev(dev);
> +}
> +
> +static int br_vlan_has_upper_bind_vlan_dev(struct net_device *dev)
> +{
> +	int found;
> +
> +	rcu_read_lock();
> +	found = netdev_walk_all_upper_dev_rcu(dev, br_vlan_is_bind_vlan_dev_fn,
> +					      NULL);
> +	rcu_read_unlock();
> +
> +	return found;
> +}
> +
> +struct br_vlan_bind_walk_data {
> +	u16 vid;
> +	struct net_device *result;
> +};
> +
> +static int br_vlan_match_bind_vlan_dev_fn(struct net_device *dev, void *data_in)
> +{
> +	struct br_vlan_bind_walk_data *data = data_in;
> +	int found = 0;
> +
> +	if (br_vlan_is_bind_vlan_dev(dev) &&
> +	    vlan_dev_priv(dev)->vlan_id == data->vid) {
> +		dev_hold(dev);

Why do you need dev_hold() ?
This seems to be running under rtnl.

> +		data->result = dev;
> +		found = 1;
> +	}
> +
> +	return found;
> +}
> +
> +/* If found, returns the vlan device with a reference held, else returns NULL.
> + */
> +static struct net_device *
> +br_vlan_get_upper_bind_vlan_dev(struct net_device *dev, u16 vid)
> +{
> +	struct br_vlan_bind_walk_data data = {
> +		.vid = vid,
> +	};
> +
> +	rcu_read_lock();
> +	netdev_walk_all_upper_dev_rcu(dev, br_vlan_match_bind_vlan_dev_fn,
> +				      &data);
> +	rcu_read_unlock();
> +
> +	return data.result;
> +}
> +
> +static bool br_vlan_is_dev_up(struct net_device *dev)

const dev

> +{
> +	return  !!(dev->flags & IFF_UP) && netif_oper_up(dev);
> +}
> +
> +static void br_vlan_set_vlan_dev_state(struct net_bridge *br,
> +				       struct net_device *vlan_dev)
> +{
> +	u16 vid = vlan_dev_priv(vlan_dev)->vlan_id;
> +	struct net_bridge_vlan_group *vg;
> +	struct net_bridge_port *p;
> +	bool has_carrier = false;
> +
> +	list_for_each_entry(p, &br->port_list, list) {
> +		vg = nbp_vlan_group(p);
> +		if (br_vlan_find(vg, vid) && br_vlan_is_dev_up(p->dev)) {
> +			has_carrier = true;
> +			break;
> +		}
> +	}
> +
> +	if (netif_carrier_ok(vlan_dev)) {
> +		if (!has_carrier)
> +			netif_carrier_off(vlan_dev);
> +	} else {
> +		if (has_carrier)
> +			netif_carrier_on(vlan_dev);
> +	}
> +}
> +
> +static void br_vlan_set_all_vlan_dev_state(struct net_bridge_port *p,
> +					   struct net_bridge *br)

br is redundant, you can access it via p->br, you can define it locally
if needed

> +{
> +	struct net_bridge_vlan_group *vg = nbp_vlan_group(p);
> +	struct net_bridge_vlan *vlan;
> +	struct net_device *vlan_dev;
> +
> +	list_for_each_entry(vlan, &vg->vlan_list, vlist) {
> +		vlan_dev = br_vlan_get_upper_bind_vlan_dev(br->dev, vlan->vid);
> +		if (vlan_dev) {
> +			if (br_vlan_is_dev_up(p->dev)) {
> +				if (!netif_carrier_ok(vlan_dev))
> +					netif_carrier_on(vlan_dev);
> +			} else {
> +				br_vlan_set_vlan_dev_state(br, vlan_dev);
> +			}
> +			dev_put(vlan_dev);
> +		}
> +	}
> +}
> +
> +void br_vlan_upper_change(struct net_device *dev, struct net_device *upper_dev,
> +			  bool linking)
> +{
> +	struct net_bridge *br = netdev_priv(dev);
> +
> +	if (!br_vlan_is_bind_vlan_dev(upper_dev))
> +		return;
> +
> +	if (linking) {
> +		br_vlan_set_vlan_dev_state(br, upper_dev);
> +		br->vlan_bridge_binding = 1;
> +	} else {
> +		br->vlan_bridge_binding = br_vlan_has_upper_bind_vlan_dev(dev);
> +	}
> +}
> +
> +void br_vlan_port_event(struct net_bridge_port *p, struct net_bridge *br,
> +			unsigned long event)

br is redundant, p->br is available

> +{
> +	if (!br->vlan_bridge_binding)
> +		return;
> +
> +	switch (event) {
> +	case NETDEV_CHANGE:
> +	case NETDEV_DOWN:
> +	case NETDEV_UP:
> +		br_vlan_set_all_vlan_dev_state(p, br);
> +		break;
> +	}
> +}
> 

Re: [PATCH net-next 3/4] bridge: support binding vlan dev link state to vlan member bridge ports

[Mike Manning]

On 02/04/2019 20:22, Nikolay Aleksandrov wrote:
> On 02/04/2019 18:35, Mike Manning wrote:
>> In the case of vlan filtering on bridges, the bridge may also have the
>> corresponding vlan devices as upper devices. A vlan bridge binding mode
>> is added to allow the link state of the vlan device to track only the
>> state of the subset of bridge ports that are also members of the vlan,
>> rather than that of all bridge ports. This mode is set with a vlan flag
>> rather than a bridge sysfs so that the 8021q module is aware that it
>> should not set the link state for the vlan device.
>>
>> If bridge vlan is configured, the bridge device event handling results
>> in the link state for an upper device being set, if it is a vlan device
>> with the vlan bridge binding mode enabled. This also sets a
>> vlan_bridge_binding flag so that subsequent UP/DOWN/CHANGE events for
>> the ports in that bridge result in a link state update of the vlan
>> device if required.
>>
>> The link state of the vlan device is up if there is at least one bridge
>> port that is a vlan member that is admin & oper up, otherwise its oper
>> state is IF_OPER_LOWERLAYERDOWN.
>>
>> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
>> ---
>>  net/bridge/br.c         |  23 ++++++--
>>  net/bridge/br_private.h |  17 ++++++
>>  net/bridge/br_vlan.c    | 143 ++++++++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 179 insertions(+), 4 deletions(-)
>>
> Hi,
> Please CC bridge maintainers when sending bridge patches.
Thank you very much for the review, I will CC you and Roopa when I have
the v1 series ready.
> One question/thought - can't we add a ports_up counter in the vlan's master
> struct and keep how many ports are up for that vlan ?

This would have been my preferred choice, but for this one would need to
know the old link state for a port so as to determine if/what link state
transition has occurred for a NETDEV_CHANGE notification. This is if
only a single counter is kept for the vlan for all ports (also it might
be difficult to recover from an error in the counter). I could see it
working if one kept track of the operational state for each port in the
vlan in a data structure specific to this purpose i.e. that is more
efficient than the existing walk. However, speed in processing these
state changes is not that important, also the link state is quickly
determined when it might matter more, i.e. on link up of a port.

> The important part would be to keep it correct, i.e. vlan_add/del should inc/dec
> as well as port up/down. Then we can directly update its carrier on port event
> without doing a possible O(n^2) walk, we just need to walk over the port vlans
> and adjust counters which is always O(n) based on num of that port's vlans.
>
> Some more comments below.
I will make all the other changes you have requested.

Re: [PATCH net-next 3/4] bridge: support binding vlan dev link state to vlan member bridge ports

[Nikolay Aleksandrov]

On 03/04/2019 20:43, Mike Manning wrote:
> On 02/04/2019 20:22, Nikolay Aleksandrov wrote:
>> On 02/04/2019 18:35, Mike Manning wrote:
>>> In the case of vlan filtering on bridges, the bridge may also have the
>>> corresponding vlan devices as upper devices. A vlan bridge binding mode
>>> is added to allow the link state of the vlan device to track only the
>>> state of the subset of bridge ports that are also members of the vlan,
>>> rather than that of all bridge ports. This mode is set with a vlan flag
>>> rather than a bridge sysfs so that the 8021q module is aware that it
>>> should not set the link state for the vlan device.
>>>
>>> If bridge vlan is configured, the bridge device event handling results
>>> in the link state for an upper device being set, if it is a vlan device
>>> with the vlan bridge binding mode enabled. This also sets a
>>> vlan_bridge_binding flag so that subsequent UP/DOWN/CHANGE events for
>>> the ports in that bridge result in a link state update of the vlan
>>> device if required.
>>>
>>> The link state of the vlan device is up if there is at least one bridge
>>> port that is a vlan member that is admin & oper up, otherwise its oper
>>> state is IF_OPER_LOWERLAYERDOWN.
>>>
>>> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
>>> ---
>>>  net/bridge/br.c         |  23 ++++++--
>>>  net/bridge/br_private.h |  17 ++++++
>>>  net/bridge/br_vlan.c    | 143 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>  3 files changed, 179 insertions(+), 4 deletions(-)
>>>
>> Hi,
>> Please CC bridge maintainers when sending bridge patches.
> Thank you very much for the review, I will CC you and Roopa when I have
> the v1 series ready.
>> One question/thought - can't we add a ports_up counter in the vlan's master
>> struct and keep how many ports are up for that vlan ?
> 
> This would have been my preferred choice, but for this one would need to
> know the old link state for a port so as to determine if/what link state
> transition has occurred for a NETDEV_CHANGE notification. This is if
> only a single counter is kept for the vlan for all ports (also it might
> be difficult to recover from an error in the counter). I could see it
> working if one kept track of the operational state for each port in the
> vlan in a data structure specific to this purpose i.e. that is more
> efficient than the existing walk. However, speed in processing these
> state changes is not that important, also the link state is quickly
> determined when it might matter more, i.e. on link up of a port.
> 

Indeed, the NETDEV_CHANGE is harder, but we can keep the last known carrier state
in the per-port structure and make a decision based on that and the new state.
That wouldn't require any additional structures. Speed is important to us when
we deploy the bridge at scale, we have tests with thousands of vlans and devices
where this walk would become expensive on link flaps.

>> The important part would be to keep it correct, i.e. vlan_add/del should inc/dec
>> as well as port up/down. Then we can directly update its carrier on port event
>> without doing a possible O(n^2) walk, we just need to walk over the port vlans
>> and adjust counters which is always O(n) based on num of that port's vlans.
>>
>> Some more comments below.
> I will make all the other changes you have requested.
> 

Thanks!

Re: [PATCH net-next 3/4] bridge: support binding vlan dev link state to vlan member bridge ports

[Nikolay Aleksandrov]

On 03/04/2019 20:53, Nikolay Aleksandrov wrote:
> On 03/04/2019 20:43, Mike Manning wrote:
>> On 02/04/2019 20:22, Nikolay Aleksandrov wrote:
>>> On 02/04/2019 18:35, Mike Manning wrote:
>>>> In the case of vlan filtering on bridges, the bridge may also have the
>>>> corresponding vlan devices as upper devices. A vlan bridge binding mode
>>>> is added to allow the link state of the vlan device to track only the
>>>> state of the subset of bridge ports that are also members of the vlan,
>>>> rather than that of all bridge ports. This mode is set with a vlan flag
>>>> rather than a bridge sysfs so that the 8021q module is aware that it
>>>> should not set the link state for the vlan device.
>>>>
>>>> If bridge vlan is configured, the bridge device event handling results
>>>> in the link state for an upper device being set, if it is a vlan device
>>>> with the vlan bridge binding mode enabled. This also sets a
>>>> vlan_bridge_binding flag so that subsequent UP/DOWN/CHANGE events for
>>>> the ports in that bridge result in a link state update of the vlan
>>>> device if required.
>>>>
>>>> The link state of the vlan device is up if there is at least one bridge
>>>> port that is a vlan member that is admin & oper up, otherwise its oper
>>>> state is IF_OPER_LOWERLAYERDOWN.
>>>>
>>>> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
>>>> ---
>>>>  net/bridge/br.c         |  23 ++++++--
>>>>  net/bridge/br_private.h |  17 ++++++
>>>>  net/bridge/br_vlan.c    | 143 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>  3 files changed, 179 insertions(+), 4 deletions(-)
>>>>
>>> Hi,
>>> Please CC bridge maintainers when sending bridge patches.
>> Thank you very much for the review, I will CC you and Roopa when I have
>> the v1 series ready.
>>> One question/thought - can't we add a ports_up counter in the vlan's master
>>> struct and keep how many ports are up for that vlan ?
>>
>> This would have been my preferred choice, but for this one would need to
>> know the old link state for a port so as to determine if/what link state
>> transition has occurred for a NETDEV_CHANGE notification. This is if
>> only a single counter is kept for the vlan for all ports (also it might
>> be difficult to recover from an error in the counter). I could see it
>> working if one kept track of the operational state for each port in the
>> vlan in a data structure specific to this purpose i.e. that is more
>> efficient than the existing walk. However, speed in processing these
>> state changes is not that important, also the link state is quickly
>> determined when it might matter more, i.e. on link up of a port.
>>
> 
> Indeed, the NETDEV_CHANGE is harder, but we can keep the last known carrier state
> in the per-port structure and make a decision based on that and the new state.
> That wouldn't require any additional structures. Speed is important to us when
> we deploy the bridge at scale, we have tests with thousands of vlans and devices
> where this walk would become expensive on link flaps.
> 

In fact we already have a similar tracking field used for the port state, maybe
it can be used as an indicator. That state needs to be taken into account anyway
or the carrier state would be wrong.

>>> The important part would be to keep it correct, i.e. vlan_add/del should inc/dec
>>> as well as port up/down. Then we can directly update its carrier on port event
>>> without doing a possible O(n^2) walk, we just need to walk over the port vlans
>>> and adjust counters which is always O(n) based on num of that port's vlans.
>>>
>>> Some more comments below.
>> I will make all the other changes you have requested.
>>
> 
> Thanks!
> 

Re: [PATCH net-next 3/4] bridge: support binding vlan dev link state to vlan member bridge ports

[Nikolay Aleksandrov]

On 03/04/2019 21:17, Nikolay Aleksandrov wrote:
> On 03/04/2019 20:53, Nikolay Aleksandrov wrote:
>> On 03/04/2019 20:43, Mike Manning wrote:
>>> On 02/04/2019 20:22, Nikolay Aleksandrov wrote:
>>>> On 02/04/2019 18:35, Mike Manning wrote:
>>>>> In the case of vlan filtering on bridges, the bridge may also have the
>>>>> corresponding vlan devices as upper devices. A vlan bridge binding mode
>>>>> is added to allow the link state of the vlan device to track only the
>>>>> state of the subset of bridge ports that are also members of the vlan,
>>>>> rather than that of all bridge ports. This mode is set with a vlan flag
>>>>> rather than a bridge sysfs so that the 8021q module is aware that it
>>>>> should not set the link state for the vlan device.
>>>>>
>>>>> If bridge vlan is configured, the bridge device event handling results
>>>>> in the link state for an upper device being set, if it is a vlan device
>>>>> with the vlan bridge binding mode enabled. This also sets a
>>>>> vlan_bridge_binding flag so that subsequent UP/DOWN/CHANGE events for
>>>>> the ports in that bridge result in a link state update of the vlan
>>>>> device if required.
>>>>>
>>>>> The link state of the vlan device is up if there is at least one bridge
>>>>> port that is a vlan member that is admin & oper up, otherwise its oper
>>>>> state is IF_OPER_LOWERLAYERDOWN.
>>>>>
>>>>> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
>>>>> ---
>>>>>  net/bridge/br.c         |  23 ++++++--
>>>>>  net/bridge/br_private.h |  17 ++++++
>>>>>  net/bridge/br_vlan.c    | 143 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>  3 files changed, 179 insertions(+), 4 deletions(-)
>>>>>
>>>> Hi,
>>>> Please CC bridge maintainers when sending bridge patches.
>>> Thank you very much for the review, I will CC you and Roopa when I have
>>> the v1 series ready.
>>>> One question/thought - can't we add a ports_up counter in the vlan's master
>>>> struct and keep how many ports are up for that vlan ?
>>>
>>> This would have been my preferred choice, but for this one would need to
>>> know the old link state for a port so as to determine if/what link state
>>> transition has occurred for a NETDEV_CHANGE notification. This is if
>>> only a single counter is kept for the vlan for all ports (also it might
>>> be difficult to recover from an error in the counter). I could see it
>>> working if one kept track of the operational state for each port in the
>>> vlan in a data structure specific to this purpose i.e. that is more
>>> efficient than the existing walk. However, speed in processing these
>>> state changes is not that important, also the link state is quickly
>>> determined when it might matter more, i.e. on link up of a port.
>>>
>>
>> Indeed, the NETDEV_CHANGE is harder, but we can keep the last known carrier state
>> in the per-port structure and make a decision based on that and the new state.
>> That wouldn't require any additional structures. Speed is important to us when
>> we deploy the bridge at scale, we have tests with thousands of vlans and devices
>> where this walk would become expensive on link flaps.
>>
> 
> In fact we already have a similar tracking field used for the port state, maybe
> it can be used as an indicator. That state needs to be taken into account anyway
> or the carrier state would be wrong.
> 

Nevermind the last sentence, spoke too quickly. An additional structure may be needed
after all, this will need some investigating.

>>>> The important part would be to keep it correct, i.e. vlan_add/del should inc/dec
>>>> as well as port up/down. Then we can directly update its carrier on port event
>>>> without doing a possible O(n^2) walk, we just need to walk over the port vlans
>>>> and adjust counters which is always O(n) based on num of that port's vlans.
>>>>
>>>> Some more comments below.
>>> I will make all the other changes you have requested.
>>>
>>
>> Thanks!
>>
> 

Re: [PATCH net-next 3/4] bridge: support binding vlan dev link state to vlan member bridge ports

[Mike Manning]

On 03/04/2019 19:23, Nikolay Aleksandrov wrote:
> On 03/04/2019 21:17, Nikolay Aleksandrov wrote:
>> On 03/04/2019 20:53, Nikolay Aleksandrov wrote:
>>> On 03/04/2019 20:43, Mike Manning wrote:
>>>> On 02/04/2019 20:22, Nikolay Aleksandrov wrote:
>>>>> On 02/04/2019 18:35, Mike Manning wrote:
>>>>>> In the case of vlan filtering on bridges, the bridge may also have the
>>>>>> corresponding vlan devices as upper devices. A vlan bridge binding mode
>>>>>> is added to allow the link state of the vlan device to track only the
>>>>>> state of the subset of bridge ports that are also members of the vlan,
>>>>>> rather than that of all bridge ports. This mode is set with a vlan flag
>>>>>> rather than a bridge sysfs so that the 8021q module is aware that it
>>>>>> should not set the link state for the vlan device.
>>>>>>
>>>>>> If bridge vlan is configured, the bridge device event handling results
>>>>>> in the link state for an upper device being set, if it is a vlan device
>>>>>> with the vlan bridge binding mode enabled. This also sets a
>>>>>> vlan_bridge_binding flag so that subsequent UP/DOWN/CHANGE events for
>>>>>> the ports in that bridge result in a link state update of the vlan
>>>>>> device if required.
>>>>>>
>>>>>> The link state of the vlan device is up if there is at least one bridge
>>>>>> port that is a vlan member that is admin & oper up, otherwise its oper
>>>>>> state is IF_OPER_LOWERLAYERDOWN.
>>>>>>
>>>>>> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
>>>>>> ---
>>>>>>  net/bridge/br.c         |  23 ++++++--
>>>>>>  net/bridge/br_private.h |  17 ++++++
>>>>>>  net/bridge/br_vlan.c    | 143 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>  3 files changed, 179 insertions(+), 4 deletions(-)
>>>>>>
>>>>> Hi,
>>>>> Please CC bridge maintainers when sending bridge patches.
>>>> Thank you very much for the review, I will CC you and Roopa when I have
>>>> the v1 series ready.
>>>>> One question/thought - can't we add a ports_up counter in the vlan's master
>>>>> struct and keep how many ports are up for that vlan ?
>>>> This would have been my preferred choice, but for this one would need to
>>>> know the old link state for a port so as to determine if/what link state
>>>> transition has occurred for a NETDEV_CHANGE notification. This is if
>>>> only a single counter is kept for the vlan for all ports (also it might
>>>> be difficult to recover from an error in the counter). I could see it
>>>> working if one kept track of the operational state for each port in the
>>>> vlan in a data structure specific to this purpose i.e. that is more
>>>> efficient than the existing walk. However, speed in processing these
>>>> state changes is not that important, also the link state is quickly
>>>> determined when it might matter more, i.e. on link up of a port.
>>>>
>>> Indeed, the NETDEV_CHANGE is harder, but we can keep the last known carrier state
>>> in the per-port structure and make a decision based on that and the new state.
>>> That wouldn't require any additional structures. Speed is important to us when
>>> we deploy the bridge at scale, we have tests with thousands of vlans and devices
>>> where this walk would become expensive on link flaps.
>>>
>> In fact we already have a similar tracking field used for the port state, maybe
>> it can be used as an indicator. That state needs to be taken into account anyway
>> or the carrier state would be wrong.
>>
> Nevermind the last sentence, spoke too quickly. An additional structure may be needed
> after all, this will need some investigating.
>
>>>>> The important part would be to keep it correct, i.e. vlan_add/del should inc/dec
>>>>> as well as port up/down. Then we can directly update its carrier on port event
>>>>> without doing a possible O(n^2) walk, we just need to walk over the port vlans
>>>>> and adjust counters which is always O(n) based on num of that port's vlans.
>>>>>
>>>>> Some more comments below.
>>>> I will make all the other changes you have requested.
>>>>
>>> Thanks!
>>>
I have made the other changes in the v2 series about to be sent,
including adding a patch for handling link down on the bridge device to
cover the STP case.

However, I don't see a straightforward mechanism that is not error-prone
in terms of a new structure for storing the required link state of all
ports for all vlan devices (as one needs to track addition/deletion of
vlan devices for vlans, and addition/deletion of ports as members of
these vlans) so that one does not have to use the existing structures
for checking vlan devices and ports in those vlans.

Given that the proposed functionality is optional and so does not impact
any existing use-cases, is performance such a consideration? And
typically one would expect most ports to be up, in which case the link
state of the vlan device is set to up without having to check the state
of other ports, or at least not having to check many ports.

[PATCH net-next 4/4] bridge: update vlan dev state when port added to or deleted from vlan

[Mike Manning]

If vlan bridge binding is enabled, then the link state of a vlan device
that is an upper device of the bridge should track the state of bridge
ports that are members of that vlan. So if a bridge port becomes or
stops being a member of a vlan, then update the link state of the
vlan device if necessary.

Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
---
 net/bridge/br_vlan.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 642373231386..7c11607cf1f4 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -7,6 +7,9 @@
 #include "br_private.h"
 #include "br_private_tunnel.h"
 
+static void nbp_vlan_set_vlan_dev_state(struct net_bridge_port *p,
+					struct net_bridge *br, u16 vid);
+
 static inline int br_vlan_cmp(struct rhashtable_compare_arg *arg,
 			      const void *ptr)
 {
@@ -294,6 +297,9 @@ static int __vlan_add(struct net_bridge_vlan *v, u16 flags,
 
 	__vlan_add_list(v);
 	__vlan_add_flags(v, flags);
+
+	if (p)
+		nbp_vlan_set_vlan_dev_state(p, br, v->vid);
 out:
 	return err;
 
@@ -358,6 +364,8 @@ static int __vlan_del(struct net_bridge_vlan *v)
 		rhashtable_remove_fast(&vg->vlan_hash, &v->vnode,
 				       br_vlan_rht_params);
 		__vlan_del_list(v);
+		if (p)
+			nbp_vlan_set_vlan_dev_state(p, p->br, v->vid);
 		call_rcu(&v->rcu, nbp_vlan_rcu_free);
 	}
 
@@ -1357,6 +1365,21 @@ static void br_vlan_set_vlan_dev_state(struct net_bridge *br,
 	}
 }
 
+static void nbp_vlan_set_vlan_dev_state(struct net_bridge_port *p,
+					struct net_bridge *br, u16 vid)
+{
+	struct net_device *vlan_dev;
+
+	if (!br->vlan_bridge_binding)
+		return;
+
+	vlan_dev = br_vlan_get_upper_bind_vlan_dev(br->dev, vid);
+	if (vlan_dev) {
+		br_vlan_set_vlan_dev_state(br, vlan_dev);
+		dev_put(vlan_dev);
+	}
+}
+
 static void br_vlan_set_all_vlan_dev_state(struct net_bridge_port *p,
 					   struct net_bridge *br)
 {
-- 
2.11.0

Re: [PATCH net-next 4/4] bridge: update vlan dev state when port added to or deleted from vlan

[Nikolay Aleksandrov]

On 02/04/2019 18:35, Mike Manning wrote:
> If vlan bridge binding is enabled, then the link state of a vlan device
> that is an upper device of the bridge should track the state of bridge
> ports that are members of that vlan. So if a bridge port becomes or
> stops being a member of a vlan, then update the link state of the
> vlan device if necessary.
> 
> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
> ---
>  net/bridge/br_vlan.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> index 642373231386..7c11607cf1f4 100644
> --- a/net/bridge/br_vlan.c
> +++ b/net/bridge/br_vlan.c
> @@ -7,6 +7,9 @@
>  #include "br_private.h"
>  #include "br_private_tunnel.h"
>  
> +static void nbp_vlan_set_vlan_dev_state(struct net_bridge_port *p,
> +					struct net_bridge *br, u16 vid);
> +
>  static inline int br_vlan_cmp(struct rhashtable_compare_arg *arg,
>  			      const void *ptr)
>  {
> @@ -294,6 +297,9 @@ static int __vlan_add(struct net_bridge_vlan *v, u16 flags,
>  
>  	__vlan_add_list(v);
>  	__vlan_add_flags(v, flags);
> +
> +	if (p)
> +		nbp_vlan_set_vlan_dev_state(p, br, v->vid);

since you need this as a last action after vlan_add and acts only on ports
why not move it to nbp_vlan_add() ?

>  out:
>  	return err;
>  
> @@ -358,6 +364,8 @@ static int __vlan_del(struct net_bridge_vlan *v)
>  		rhashtable_remove_fast(&vg->vlan_hash, &v->vnode,
>  				       br_vlan_rht_params);
>  		__vlan_del_list(v);
> +		if (p)
> +			nbp_vlan_set_vlan_dev_state(p, p->br, v->vid);

p is guaranteed to be set here, but also there's an if (p) earlier in the function.
this can probably also move to nbp_vlan_delete if the other set_state moves to 
nbp_vlan_add

>  		call_rcu(&v->rcu, nbp_vlan_rcu_free);
>  	}
>  
> @@ -1357,6 +1365,21 @@ static void br_vlan_set_vlan_dev_state(struct net_bridge *br,
>  	}
>  }
>  
> +static void nbp_vlan_set_vlan_dev_state(struct net_bridge_port *p,
> +					struct net_bridge *br, u16 vid)
> +{
> +	struct net_device *vlan_dev;
> +
> +	if (!br->vlan_bridge_binding)
> +		return;
> +
> +	vlan_dev = br_vlan_get_upper_bind_vlan_dev(br->dev, vid);
> +	if (vlan_dev) {
> +		br_vlan_set_vlan_dev_state(br, vlan_dev);
> +		dev_put(vlan_dev);

I think this is running under rtnl.

> +	}
> +}
> +
>  static void br_vlan_set_all_vlan_dev_state(struct net_bridge_port *p,
>  					   struct net_bridge *br)
>  {
> 

Re: [PATCH net-next 4/4] bridge: update vlan dev state when port added to or deleted from vlan

[Mike Manning]

On 02/04/2019 21:10, Nikolay Aleksandrov wrote:
> On 02/04/2019 18:35, Mike Manning wrote:
>> If vlan bridge binding is enabled, then the link state of a vlan device
>> that is an upper device of the bridge should track the state of bridge
>> ports that are members of that vlan. So if a bridge port becomes or
>> stops being a member of a vlan, then update the link state of the
>> vlan device if necessary.
>>
>> Signed-off-by: Mike Manning <mmanning@vyatta.att-mail.com>
>> ---
>>  net/bridge/br_vlan.c | 23 +++++++++++++++++++++++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
>> index 642373231386..7c11607cf1f4 100644
>> --- a/net/bridge/br_vlan.c
>> +++ b/net/bridge/br_vlan.c
>> @@ -7,6 +7,9 @@
>>  #include "br_private.h"
>>  #include "br_private_tunnel.h"
>>  
>> +static void nbp_vlan_set_vlan_dev_state(struct net_bridge_port *p,
>> +					struct net_bridge *br, u16 vid);
>> +
>>  static inline int br_vlan_cmp(struct rhashtable_compare_arg *arg,
>>  			      const void *ptr)
>>  {
>> @@ -294,6 +297,9 @@ static int __vlan_add(struct net_bridge_vlan *v, u16 flags,
>>  
>>  	__vlan_add_list(v);
>>  	__vlan_add_flags(v, flags);
>> +
>> +	if (p)
>> +		nbp_vlan_set_vlan_dev_state(p, br, v->vid);
> since you need this as a last action after vlan_add and acts only on ports
> why not move it to nbp_vlan_add() ?
The call is in __vlan_add() rather than nbp_vlan_add() only for reasons
of consistency with the delete case, please see below.
>
>>  out:
>>  	return err;
>>  
>> @@ -358,6 +364,8 @@ static int __vlan_del(struct net_bridge_vlan *v)
>>  		rhashtable_remove_fast(&vg->vlan_hash, &v->vnode,
>>  				       br_vlan_rht_params);
>>  		__vlan_del_list(v);
>> +		if (p)
>> +			nbp_vlan_set_vlan_dev_state(p, p->br, v->vid);
> p is guaranteed to be set here, but also there's an if (p) earlier in the function.
> this can probably also move to nbp_vlan_delete if the other set_state moves to 
> nbp_vlan_add
>
Agreed re p being set here, I was just safeguarding against future
changes where this might not be true, but I will get rid of this.

The call is made here so as to be after the removal of the node from the
rhashtable.

The check is also needed as a result of calling nbp_vlan_flush(), hence
making the call here rather than in nbp_vlan_delete().

>>  		call_rcu(&v->rcu, nbp_vlan_rcu_free);
>>  	}
>>  
>> @@ -1357,6 +1365,21 @@ static void br_vlan_set_vlan_dev_state(struct net_bridge *br,
>>  	}
>>  }
>>  
>> +static void nbp_vlan_set_vlan_dev_state(struct net_bridge_port *p,
>> +					struct net_bridge *br, u16 vid)
>> +{
>> +	struct net_device *vlan_dev;
>> +
>> +	if (!br->vlan_bridge_binding)
>> +		return;
>> +
>> +	vlan_dev = br_vlan_get_upper_bind_vlan_dev(br->dev, vid);
>> +	if (vlan_dev) {
>> +		br_vlan_set_vlan_dev_state(br, vlan_dev);
>> +		dev_put(vlan_dev);
> I think this is running under rtnl.
Agreed, I will get rid of this and the other instance of this use.