net: dsa: tag_dsa: send packets with TX fwd offload from VLAN-unaware bridges using...

The present code is structured this way due to an incomplete thought
process. In Documentation/networking/switchdev.rst we document that if a
bridge is VLAN-unaware, then the presence or lack of a pvid on a bridge
port (or on the bridge itself, for that matter) should not affect the
ability to receive and transmit tagged or untagged packets.

If the bridge on behalf of which we are sending this packet is
VLAN-aware, then the TX forwarding offload API ensures that the skb will
be VLAN-tagged (if the packet was sent by user space as untagged, it
will get transmitted town to the driver as tagged with the bridge
device's pvid). But if the bridge is VLAN-unaware, it may or may not be
VLAN-tagged. In fact the logic to insert the bridge's PVID came from the
idea that we should emulate what is being done in the VLAN-aware case.
But we shouldn't.

It appears that injecting packets using a VLAN ID of 0 serves the
purpose of forwarding the packets to the egress port with no VLAN tag
added or stripped by the hardware, and no filtering being performed.
So we can simply remove the superfluous logic.

One reason why this logic is broken is that when CONFIG_BRIDGE_VLAN_FILTERING=n,
we call br_vlan_get_pvid_rcu() but that returns an error and we do error
out, dropping all packets on xmit. Not really smart. This is also an
issue when the user deletes the bridge pvid:

$ bridge vlan del dev br0 vid 1 self

As mentioned, in both cases, packets should still flow freely, and they
do just that on any net device where the bridge is not offloaded, but on
mv88e6xxx they don't.

Fixes: d82f8ab0d874 ("net: dsa: tag_dsa: offload the bridge forwarding process")
Reported-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003155141.2241314-1-andrew@lunn.ch/
Link: https://patchwork.kernel.org/project/netdevbpf/patch/20210928233708.1246774-1-vladimir.oltean@nxp.com/
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>

diff --git a/net/dsa/tag_dsa.c b/net/dsa/tag_dsa.c
index e5127b7d1c6a58f08a4be7fe878f7eed93398a52..68d5ddc3ef3532c85b5f717a0c5222ee5b7c9d59 100644 (file)
--- a/net/dsa/tag_dsa.c
+++ b/net/dsa/tag_dsa.c
@@ -129,12 +129,9 @@ static struct sk_buff *dsa_xmit_ll(struct sk_buff *skb, struct net_device *dev,
        u8 tag_dev, tag_port;
        enum dsa_cmd cmd;
        u8 *dsa_header;
-       u16 pvid = 0;
-       int err;
 
        if (skb->offload_fwd_mark) {
                struct dsa_switch_tree *dst = dp->ds->dst;
-               struct net_device *br = dp->bridge_dev;
 
                cmd = DSA_CMD_FORWARD;
 
@@ -144,19 +141,6 @@ static struct sk_buff *dsa_xmit_ll(struct sk_buff *skb, struct net_device *dev,
                 */
                tag_dev = dst->last_switch + 1 + dp->bridge_num;
                tag_port = 0;
-
-               /* If we are offloading forwarding for a VLAN-unaware bridge,
-                * inject packets to hardware using the bridge's pvid, since
-                * that's where the packets ingressed from.
-                */
-               if (!br_vlan_enabled(br)) {
-                       /* Safe because __dev_queue_xmit() runs under
-                        * rcu_read_lock_bh()
-                        */
-                       err = br_vlan_get_pvid_rcu(br, &pvid);
-                       if (err)
-                               return NULL;
-               }
        } else {
                cmd = DSA_CMD_FROM_CPU;
                tag_dev = dp->ds->index;
@@ -188,8 +172,8 @@ static struct sk_buff *dsa_xmit_ll(struct sk_buff *skb, struct net_device *dev,
 
                dsa_header[0] = (cmd << 6) | tag_dev;
                dsa_header[1] = tag_port << 3;
-               dsa_header[2] = pvid >> 8;
-               dsa_header[3] = pvid & 0xff;
+               dsa_header[2] = 0;
+               dsa_header[3] = 0;
        }
 
        return skb;