From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>,
"olteanv@gmail.com" <olteanv@gmail.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
Roopa Prabhu <roopa@nvidia.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"andrew@lunn.ch" <andrew@lunn.ch>
Subject: Re: [PATCH net-next] net: bridge: pop vlan from skb if filtering is disabled but it's a pvid
Date: Sat, 12 Sep 2020 06:56:12 +0000 [thread overview]
Message-ID: <ddfecf408d3d1b7e4af97cb3b1c1c63506e4218e.camel@nvidia.com> (raw)
In-Reply-To: <20200911231619.2876486-1-olteanv@gmail.com>
On Sat, 2020-09-12 at 02:16 +0300, Vladimir Oltean wrote:
> Currently the bridge untags VLANs from its VLAN group in
> __allowed_ingress() only when VLAN filtering is enabled.
>
> When installing a pvid in egress-tagged mode, DSA switches have a
> problem:
>
> ip link add dev br0 type bridge vlan_filtering 0
> ip link set swp0 master br0
> bridge vlan del dev swp0 vid 1
> bridge vlan add dev swp0 vid 1 pvid
>
> When adding a VLAN on a DSA switch interface, DSA configures the VLAN
> membership of the CPU port using the same flags as swp0 (in this case
> "pvid and not untagged"), in an attempt to copy the frame as-is from
> ingress to the CPU.
>
> However, in this case, the packet may arrive untagged on ingress, it
> will be pvid-tagged by the ingress port, and will be sent as
> egress-tagged towards the CPU. Otherwise stated, the CPU will see a VLAN
> tag where there was none to speak of on ingress.
>
> When vlan_filtering is 1, this is not a problem, as stated in the first
> paragraph, because __allowed_ingress() will pop it. But currently, when
> vlan_filtering is 0 and we have such a VLAN configuration, we need an
> 8021q upper (br0.1) to be able to ping over that VLAN.
>
> Make the 2 cases (vlan_filtering 0 and 1) behave the same way by popping
> the pvid, if the skb happens to be tagged with it, when vlan_filtering
> is 0.
>
> There was an attempt to resolve this issue locally within the DSA
> receive data path, but even though we can determine that we are under a
> bridge with vlan_filtering=0, there are still some challenges:
> - we cannot be certain that the skb will end up in the software bridge's
> data path, and for that reason, we may be popping the VLAN for
> nothing. Example: there might exist an 8021q upper with the same VLAN,
> or this interface might be a DSA master for another switch. In that
> case, the VLAN should definitely not be popped even if it is equal to
> the default_pvid of the bridge, because it will be consumed about the
> DSA layer below.
Could you point me to a thread where these problems were discussed and why
they couldn't be resolved within DSA in detail ?
> - the bridge API only offers a race-free API for determining the pvid of
> a port, br_vlan_get_pvid(), under RTNL.
>
The API can be easily extended.
> And in fact this might not even be a situation unique to DSA. Any driver
> that receives untagged frames as pvid-tagged is now able to communicate
> without needing an 8021q upper for the pvid.
>
I would prefer we don't add hardware/driver-specific fixes in the bridge, when
vlan filtering is disabled there should be no vlan manipulation/filtering done
by the bridge. This could potentially break users who have added 8021q devices
as bridge ports. At the very least this needs to be hidden behind a new option,
but I would like to find a way to actually push it back to DSA. But again adding
hardware/driver-specific options should be avoided.
Can you use tc to pop the vlan on ingress ? I mean the cases above are visible
to the user, so they might decide to add the ingress vlan rule.
Thanks,
Nik
> Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
> Tested-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> net/bridge/br_vlan.c | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
> index d2b8737f9fc0..ecfdb9cd3183 100644
> --- a/net/bridge/br_vlan.c
> +++ b/net/bridge/br_vlan.c
> @@ -580,7 +580,23 @@ bool br_allowed_ingress(const struct net_bridge *br,
> * permitted.
> */
> if (!br_opt_get(br, BROPT_VLAN_ENABLED)) {
> + u16 v;
> +
> BR_INPUT_SKB_CB(skb)->vlan_filtered = false;
> +
> + /* See comment in __allowed_ingress about how skb can end up
> + * here not having a hwaccel tag
> + */
> + if (unlikely(!skb_vlan_tag_present(skb) &&
> + skb->protocol == br->vlan_proto)) {
> + skb = skb_vlan_untag(skb);
> + if (unlikely(!skb))
> + return false;
> + }
> +
> + if (!br_vlan_get_tag(skb, &v) && v == br_get_pvid(vg))
> + __vlan_hwaccel_clear_tag(skb);
> +
> return true;
> }
>
next prev parent reply other threads:[~2020-09-12 6:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-11 23:16 [PATCH net-next] net: bridge: pop vlan from skb if filtering is disabled but it's a pvid Vladimir Oltean
2020-09-12 6:56 ` Nikolay Aleksandrov [this message]
2020-09-12 7:23 ` Vladimir Oltean
2020-09-12 7:37 ` Nikolay Aleksandrov
2020-09-12 7:50 ` Vladimir Oltean
2020-09-12 19:38 ` Florian Fainelli
2020-09-14 7:51 ` Nikolay Aleksandrov
2020-09-14 20:11 ` Florian Fainelli
2020-09-21 19:44 ` Florian Fainelli
2020-09-21 19:56 ` Vladimir Oltean
2020-09-21 22:12 ` Vladimir Oltean
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ddfecf408d3d1b7e4af97cb3b1c1c63506e4218e.camel@nvidia.com \
--to=nikolay@nvidia.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=roopa@nvidia.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox