From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
To: vyasevic@redhat.com
Cc: Stephen Hemminger <stephen@networkplumber.org>,
netdev@vger.kernel.org, bridge@lists.linux-foundation.org
Subject: Re: [PATCH RFC 2/3] bridge: Prepare for 802.1ad vlan filtering support
Date: Thu, 13 Mar 2014 21:33:37 +0900 [thread overview]
Message-ID: <1394714017.4078.51.camel@ubuntu-vm-makita> (raw)
In-Reply-To: <532098D2.6050504@redhat.com>
On Wed, 2014-03-12 at 13:26 -0400, Vlad Yasevich wrote:
> On 03/10/2014 04:11 AM, Toshiaki Makita wrote:
> > This enables a bridge to have vlan protocol informantion and allows vlan
> > filtering code to take vlan protocols into account.
...
> > @@ -173,16 +174,27 @@ bool br_allowed_ingress(struct net_bridge *br, struct net_port_vlans *v,
> > * ingress frame is considered to belong to this vlan.
> > */
> > *vid = pvid;
> > - if (likely(err))
> > + if (likely(err)) {
> > /* Untagged Frame. */
> > - __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), pvid);
> > - else
> > + if (vlan_tx_tag_present(skb)) {
> > + /* skb->vlan_proto was different from br->vlan_proto */
> > + skb_push(skb, ETH_HLEN);
> > + skb = __vlan_put_tag(skb, skb->vlan_proto,
> > + vlan_tx_tag_get(skb));
> > + if (unlikely(!skb))
> > + return false;
> > + skb_pull(skb, ETH_HLEN);
> > + skb_reset_mac_len(skb);
> > + }
> > + __vlan_hwaccel_put_tag(skb, proto, pvid);
>
> So this seems to be handling the case where we had a protocol mis-match.
> My question is why are we hiding this case behind our inability to
> fetch the vid from the packet.
>
> I think it might be clearer to make the protocol check explicit
> (at least if we were to continue using the approach of defining
> the protocol per bridge).
I didn't intend to handle protocol mismatch, but handle the case where
the vlan_tci we are about to use happens to be already used.
In this function, it can occur only if the frame is originally tagged
with another protocol.
However, indeed, we seem to need the check of skb->vlan_proto only at
ingress.
So it maybe makes sense to check the vid and the protocol separately.
I'm thinking of changing that code like this.
bool untagged;
...
err = br_vlan_get_tag(skb, vid);
if (!err) {
if (skb->vlan_proto != proto) {
...
skb = __vlan_put_tag(...);
...
*vid = 0;
untagged = true;
} else {
untagged = false;
}
} else {
untagged = true;
}
if (!*vid) {
...
if (likely(untagged)) {
/* Untagged Frame. */
...
} else {
/* Priority-tagged Frame.
...
}
}
>
> This code also has a side-effect that it would be permit 802.1ad packets
> on an 802.1Q bridge and possibly forward such packets encapsulated yet
> again.
Well, this is an interesting situation.
But I have no reason to restrict it.
Users can configure such an environment if they want.
Thanks,
Toshiaki Makita
next prev parent reply other threads:[~2014-03-13 12:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-10 8:11 [PATCH RFC 0/3] bridge: 802.1ad vlan protocol support Toshiaki Makita
2014-03-10 8:11 ` [PATCH RFC 1/3] bridge: Fix handling stacked vlan tags Toshiaki Makita
2014-03-10 8:11 ` [PATCH RFC 2/3] bridge: Prepare for 802.1ad vlan filtering support Toshiaki Makita
2014-03-12 17:26 ` Vlad Yasevich
2014-03-13 12:33 ` Toshiaki Makita [this message]
2014-03-13 13:53 ` Vlad Yasevich
2014-03-14 16:18 ` Toshiaki Makita
2014-03-10 8:11 ` [PATCH RFC 3/3] bridge: Support 802.1ad vlan filtering Toshiaki Makita
2014-03-10 8:11 ` [PATCH RFC iproute2] bridge: Add 802.1ad vlan support Toshiaki Makita
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=1394714017.4078.51.camel@ubuntu-vm-makita \
--to=makita.toshiaki@lab.ntt.co.jp \
--cc=bridge@lists.linux-foundation.org \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=vyasevic@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).