The intent of 412a1526d067 ("net: dsa: untag the bridge pvid from rx
skbs") is to transparently untag the bridge's default_pvid when the
Ethernet switch can only support egress tagged of that default_pvid
towards the CPU port.
Prior to this commit, users would have to configure an 802.1Q upper on
the bridge master device when the bridge is configured with
vlan_filtering=0 in order to pop the VLAN tag:
ip link add name br0 type bridge vlan_filtering=0
ip link add link br0 name br0.1 type vlan id 1
After this commit we added support for managing a switch port 802.1Q
upper but those are not usually added as bridge members, and if they do,
they do not actually require any special management, the data path would
pop the desired VLAN tag accordingly.
What we want to preserve is that use case and to manage when the user
creates that 802.1Q upper for the bridge port.
While we are it, call __vlan_find_dev_deep_rcu() which makes use the
VLAN group array which is faster.
As soon as we return the VLAN tagged SKB though it will be used by the
following call path:
netif_receive_skb_list_internal
-> __netif_receive_skb_list_core
-> __netif_receive_skb_core
-> vlan_do_receive()
which uses skb->vlan_proto, if we do not set it to the appropriate VLAN
protocol, we will leave it set to what the DSA master has set
(ETH_P_XDSA).
Fixes: 412a1526d067 ("net: dsa: untag the bridge pvid from rx skbs")
Signed-off-by: Florian Fainelli <[email protected]>
---
net/dsa/dsa_priv.h | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 0348dbab4131..3456b53d4d53 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -247,12 +247,10 @@ static inline struct sk_buff *dsa_untag_bridge_pvid(struct sk_buff *skb)
* supports because vlan_filtering is 0. In that case, we should
* definitely keep the tag, to make sure it keeps working.
*/
- netdev_for_each_upper_dev_rcu(dev, upper_dev, iter) {
- if (!is_vlan_dev(upper_dev))
- continue;
-
- if (vid == vlan_dev_vlan_id(upper_dev))
- return skb;
+ upper_dev = __vlan_find_dev_deep_rcu(br, htons(proto), vid);
+ if (upper_dev) {
+ skb->vlan_proto = vlan_dev_vlan_proto(upper_dev);
+ return skb;
}
__vlan_hwaccel_clear_tag(skb);
--
2.25.1
On Wed, Sep 30, 2020 at 01:31:03PM -0700, Florian Fainelli wrote:
> While we are it, call __vlan_find_dev_deep_rcu() which makes use the
> VLAN group array which is faster.
Not just "while at it", but I do wonder whether it isn't, in fact,
called "deep" for a reason:
/*
* Lower devices of master uppers (bonding, team) do not have
* grp assigned to themselves. Grp is assigned to upper device
* instead.
*/
I haven't tested this, but I wonder if you could actually call
__vlan_find_dev_deep_rcu() on the switch port interface and it would
cover both this and the bridge having an 8021q upper automatically?
On 9/30/2020 1:43 PM, Vladimir Oltean wrote:
> On Wed, Sep 30, 2020 at 01:31:03PM -0700, Florian Fainelli wrote:
>> While we are it, call __vlan_find_dev_deep_rcu() which makes use the
>> VLAN group array which is faster.
>
> Not just "while at it", but I do wonder whether it isn't, in fact,
> called "deep" for a reason:
>
> /*
> * Lower devices of master uppers (bonding, team) do not have
> * grp assigned to themselves. Grp is assigned to upper device
> * instead.
> */
>
> I haven't tested this, but I wonder if you could actually call
> __vlan_find_dev_deep_rcu() on the switch port interface and it would
> cover both this and the bridge having an 8021q upper automatically?
Let me give this a try.
--
Florian
On 9/30/2020 4:29 PM, Florian Fainelli wrote:
>
>
> On 9/30/2020 1:43 PM, Vladimir Oltean wrote:
>> On Wed, Sep 30, 2020 at 01:31:03PM -0700, Florian Fainelli wrote:
>>> While we are it, call __vlan_find_dev_deep_rcu() which makes use the
>>> VLAN group array which is faster.
>>
>> Not just "while at it", but I do wonder whether it isn't, in fact,
>> called "deep" for a reason:
>>
>> /*
>> * Lower devices of master uppers (bonding, team) do not have
>> * grp assigned to themselves. Grp is assigned to upper device
>> * instead.
>> */
>>
>> I haven't tested this, but I wonder if you could actually call
>> __vlan_find_dev_deep_rcu() on the switch port interface and it would
>> cover both this and the bridge having an 8021q upper automatically?
>
> Let me give this a try.
We hit the if (vlan_info) branch and we do not recurse through the
upper_dev because of that.
I still need to send a v2 to remove the now unused 'iter' variable and
fix up the bridge iproute2 command (there is no vlan_filtering=0 it is
vlan_filtering 0).
--
Florian