diff mbox series

[net-next,01/15] net: dsa: provide an option for drivers to always receive bridge VLANs

Message ID 20200510164255.19322-2-olteanv@gmail.com
State Superseded
Delegated to: David Miller
Headers show
Series Traffic support for dsa_8021q in vlan_filtering=1 mode | expand

Commit Message

Vladimir Oltean May 10, 2020, 4:42 p.m. UTC 
From: Russell King <rmk+kernel@armlinux.org.uk>

DSA assumes that a bridge which has vlan filtering disabled is not
vlan aware, and ignores all vlan configuration. However, the kernel
software bridge code allows configuration in this state.

This causes the kernel's idea of the bridge vlan state and the
hardware state to disagree, so "bridge vlan show" indicates a correct
configuration but the hardware lacks all configuration. Even worse,
enabling vlan filtering on a DSA bridge immediately blocks all traffic
which, given the output of "bridge vlan show", is very confusing.

Provide an option that drivers can set to indicate they want to receive
vlan configuration even when vlan filtering is disabled. At the very
least, this is safe for Marvell DSA bridges, which do not look up
ingress traffic in the VTU if the port is in 8021Q disabled state. It is
also safe for the Ocelot switch family. Whether this change is suitable
for all DSA bridges is not known.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 include/net/dsa.h |  1 +
 net/dsa/slave.c   | 12 ++++++++----
 2 files changed, 9 insertions(+), 4 deletions(-)

Comments

Russell King (Oracle) May 11, 2020, 11:38 a.m. UTC | #1 
On Sun, May 10, 2020 at 07:42:41PM +0300, Vladimir Oltean wrote:
> From: Russell King <rmk+kernel@armlinux.org.uk>
> 
> DSA assumes that a bridge which has vlan filtering disabled is not
> vlan aware, and ignores all vlan configuration. However, the kernel
> software bridge code allows configuration in this state.
> 
> This causes the kernel's idea of the bridge vlan state and the
> hardware state to disagree, so "bridge vlan show" indicates a correct
> configuration but the hardware lacks all configuration. Even worse,
> enabling vlan filtering on a DSA bridge immediately blocks all traffic
> which, given the output of "bridge vlan show", is very confusing.
> 
> Provide an option that drivers can set to indicate they want to receive
> vlan configuration even when vlan filtering is disabled. At the very
> least, this is safe for Marvell DSA bridges, which do not look up
> ingress traffic in the VTU if the port is in 8021Q disabled state. It is
> also safe for the Ocelot switch family. Whether this change is suitable
> for all DSA bridges is not known.
> 
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

This patch was NAK'd because of objections to the "vlan_bridge_vtu"
name.  Unfortunately, this means that the bug for Marvell switches
remains unfixed to this day.
Vladimir Oltean May 11, 2020, 11:40 a.m. UTC | #2 
On Mon, 11 May 2020 at 14:38, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Sun, May 10, 2020 at 07:42:41PM +0300, Vladimir Oltean wrote:
> > From: Russell King <rmk+kernel@armlinux.org.uk>
> >
> > DSA assumes that a bridge which has vlan filtering disabled is not
> > vlan aware, and ignores all vlan configuration. However, the kernel
> > software bridge code allows configuration in this state.
> >
> > This causes the kernel's idea of the bridge vlan state and the
> > hardware state to disagree, so "bridge vlan show" indicates a correct
> > configuration but the hardware lacks all configuration. Even worse,
> > enabling vlan filtering on a DSA bridge immediately blocks all traffic
> > which, given the output of "bridge vlan show", is very confusing.
> >
> > Provide an option that drivers can set to indicate they want to receive
> > vlan configuration even when vlan filtering is disabled. At the very
> > least, this is safe for Marvell DSA bridges, which do not look up
> > ingress traffic in the VTU if the port is in 8021Q disabled state. It is
> > also safe for the Ocelot switch family. Whether this change is suitable
> > for all DSA bridges is not known.
> >
> > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> This patch was NAK'd because of objections to the "vlan_bridge_vtu"
> name.  Unfortunately, this means that the bug for Marvell switches
> remains unfixed to this day.
>

How about "accept_vlan_while_unaware"?

> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up

Thanks,
-Vladimir
Russell King (Oracle) May 11, 2020, 11:54 a.m. UTC | #3 
On Mon, May 11, 2020 at 02:40:29PM +0300, Vladimir Oltean wrote:
> On Mon, 11 May 2020 at 14:38, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Sun, May 10, 2020 at 07:42:41PM +0300, Vladimir Oltean wrote:
> > > From: Russell King <rmk+kernel@armlinux.org.uk>
> > >
> > > DSA assumes that a bridge which has vlan filtering disabled is not
> > > vlan aware, and ignores all vlan configuration. However, the kernel
> > > software bridge code allows configuration in this state.
> > >
> > > This causes the kernel's idea of the bridge vlan state and the
> > > hardware state to disagree, so "bridge vlan show" indicates a correct
> > > configuration but the hardware lacks all configuration. Even worse,
> > > enabling vlan filtering on a DSA bridge immediately blocks all traffic
> > > which, given the output of "bridge vlan show", is very confusing.
> > >
> > > Provide an option that drivers can set to indicate they want to receive
> > > vlan configuration even when vlan filtering is disabled. At the very
> > > least, this is safe for Marvell DSA bridges, which do not look up
> > > ingress traffic in the VTU if the port is in 8021Q disabled state. It is
> > > also safe for the Ocelot switch family. Whether this change is suitable
> > > for all DSA bridges is not known.
> > >
> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> >
> > This patch was NAK'd because of objections to the "vlan_bridge_vtu"
> > name.  Unfortunately, this means that the bug for Marvell switches
> > remains unfixed to this day.
> >
> 
> How about "accept_vlan_while_unaware"?

It's up to DSA maintainers.

However, I find that rather confusing. What's "unaware"? The point of
this boolean is to program the vlan tables while vlan filtering is
disabled. "accept_vlan_while_vlan_filtering_disabled" is way too long.
Vladimir Oltean May 11, 2020, 11:59 a.m. UTC | #4 
On Mon, 11 May 2020 at 14:54, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Mon, May 11, 2020 at 02:40:29PM +0300, Vladimir Oltean wrote:
> > On Mon, 11 May 2020 at 14:38, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Sun, May 10, 2020 at 07:42:41PM +0300, Vladimir Oltean wrote:
> > > > From: Russell King <rmk+kernel@armlinux.org.uk>
> > > >
> > > > DSA assumes that a bridge which has vlan filtering disabled is not
> > > > vlan aware, and ignores all vlan configuration. However, the kernel
> > > > software bridge code allows configuration in this state.
> > > >
> > > > This causes the kernel's idea of the bridge vlan state and the
> > > > hardware state to disagree, so "bridge vlan show" indicates a correct
> > > > configuration but the hardware lacks all configuration. Even worse,
> > > > enabling vlan filtering on a DSA bridge immediately blocks all traffic
> > > > which, given the output of "bridge vlan show", is very confusing.
> > > >
> > > > Provide an option that drivers can set to indicate they want to receive
> > > > vlan configuration even when vlan filtering is disabled. At the very
> > > > least, this is safe for Marvell DSA bridges, which do not look up
> > > > ingress traffic in the VTU if the port is in 8021Q disabled state. It is
> > > > also safe for the Ocelot switch family. Whether this change is suitable
> > > > for all DSA bridges is not known.
> > > >
> > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > >
> > > This patch was NAK'd because of objections to the "vlan_bridge_vtu"
> > > name.  Unfortunately, this means that the bug for Marvell switches
> > > remains unfixed to this day.
> > >
> >
> > How about "accept_vlan_while_unaware"?
>
> It's up to DSA maintainers.
>
> However, I find that rather confusing. What's "unaware"? The point of
> this boolean is to program the vlan tables while vlan filtering is
> disabled. "accept_vlan_while_vlan_filtering_disabled" is way too long.
>

Considering the VLAN filtering modes as "disabled", "check",
"fallback" and "secure", I think a slight improvement over your
wording might be "install_vlans_while_disabled". I hope that is not
confusing and also not too long.

> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
Russell King (Oracle) May 11, 2020, 12:05 p.m. UTC | #5 
On Mon, May 11, 2020 at 02:59:12PM +0300, Vladimir Oltean wrote:
> On Mon, 11 May 2020 at 14:54, Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> >
> > On Mon, May 11, 2020 at 02:40:29PM +0300, Vladimir Oltean wrote:
> > > On Mon, 11 May 2020 at 14:38, Russell King - ARM Linux admin
> > > <linux@armlinux.org.uk> wrote:
> > > >
> > > > On Sun, May 10, 2020 at 07:42:41PM +0300, Vladimir Oltean wrote:
> > > > > From: Russell King <rmk+kernel@armlinux.org.uk>
> > > > >
> > > > > DSA assumes that a bridge which has vlan filtering disabled is not
> > > > > vlan aware, and ignores all vlan configuration. However, the kernel
> > > > > software bridge code allows configuration in this state.
> > > > >
> > > > > This causes the kernel's idea of the bridge vlan state and the
> > > > > hardware state to disagree, so "bridge vlan show" indicates a correct
> > > > > configuration but the hardware lacks all configuration. Even worse,
> > > > > enabling vlan filtering on a DSA bridge immediately blocks all traffic
> > > > > which, given the output of "bridge vlan show", is very confusing.
> > > > >
> > > > > Provide an option that drivers can set to indicate they want to receive
> > > > > vlan configuration even when vlan filtering is disabled. At the very
> > > > > least, this is safe for Marvell DSA bridges, which do not look up
> > > > > ingress traffic in the VTU if the port is in 8021Q disabled state. It is
> > > > > also safe for the Ocelot switch family. Whether this change is suitable
> > > > > for all DSA bridges is not known.
> > > > >
> > > > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > > >
> > > > This patch was NAK'd because of objections to the "vlan_bridge_vtu"
> > > > name.  Unfortunately, this means that the bug for Marvell switches
> > > > remains unfixed to this day.
> > > >
> > >
> > > How about "accept_vlan_while_unaware"?
> >
> > It's up to DSA maintainers.
> >
> > However, I find that rather confusing. What's "unaware"? The point of
> > this boolean is to program the vlan tables while vlan filtering is
> > disabled. "accept_vlan_while_vlan_filtering_disabled" is way too long.
> >
> 
> Considering the VLAN filtering modes as "disabled", "check",
> "fallback" and "secure", I think a slight improvement over your
> wording might be "install_vlans_while_disabled". I hope that is not
> confusing and also not too long.

Well, it's not only about "installing" vlans, but also about removing
them as well.  "configure_vlans_while_disabled" would probably work
better.
diff mbox series

Patch

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 312c2f067e65..c69cee85923e 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -281,6 +281,7 @@  struct dsa_switch {
 	 * settings on ports if not hardware-supported
 	 */
 	bool			vlan_filtering_is_global;
+	bool			vlan_bridge_vtu;
 
 	/* In case vlan_filtering_is_global is set, the VLAN awareness state
 	 * should be retrieved from here and not from the per-port settings.
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 61b0de52040a..e72ebff86a1f 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -314,7 +314,8 @@  static int dsa_slave_vlan_add(struct net_device *dev,
 	if (obj->orig_dev != dev)
 		return -EOPNOTSUPP;
 
-	if (dp->bridge_dev && !br_vlan_enabled(dp->bridge_dev))
+	if (dp->bridge_dev && !dp->ds->vlan_bridge_vtu &&
+	    !br_vlan_enabled(dp->bridge_dev))
 		return 0;
 
 	vlan = *SWITCHDEV_OBJ_PORT_VLAN(obj);
@@ -381,7 +382,8 @@  static int dsa_slave_vlan_del(struct net_device *dev,
 	if (obj->orig_dev != dev)
 		return -EOPNOTSUPP;
 
-	if (dp->bridge_dev && !br_vlan_enabled(dp->bridge_dev))
+	if (dp->bridge_dev && !dp->ds->vlan_bridge_vtu &&
+	    !br_vlan_enabled(dp->bridge_dev))
 		return 0;
 
 	/* Do not deprogram the CPU port as it may be shared with other user
@@ -1240,7 +1242,8 @@  static int dsa_slave_vlan_rx_add_vid(struct net_device *dev, __be16 proto,
 	 * need to emulate the switchdev prepare + commit phase.
 	 */
 	if (dp->bridge_dev) {
-		if (!br_vlan_enabled(dp->bridge_dev))
+		if (!dp->ds->vlan_bridge_vtu &&
+		    !br_vlan_enabled(dp->bridge_dev))
 			return 0;
 
 		/* br_vlan_get_info() returns -EINVAL or -ENOENT if the
@@ -1274,7 +1277,8 @@  static int dsa_slave_vlan_rx_kill_vid(struct net_device *dev, __be16 proto,
 	 * need to emulate the switchdev prepare + commit phase.
 	 */
 	if (dp->bridge_dev) {
-		if (!br_vlan_enabled(dp->bridge_dev))
+		if (!dp->ds->vlan_bridge_vtu &&
+		    !br_vlan_enabled(dp->bridge_dev))
 			return 0;
 
 		/* br_vlan_get_info() returns -EINVAL or -ENOENT if the