[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <76b7723b-68dd-0efc-9a93-0597e9d9b827@gmail.com>
Date: Tue, 3 Sep 2019 20:37:36 +0900
From: Toshiaki Makita <toshiaki.makita1@...il.com>
To: Zahari Doychev <zahari.doychev@...ux.com>, netdev@...r.kernel.org
Cc: makita.toshiaki@....ntt.co.jp, jiri@...nulli.us,
nikolay@...ulusnetworks.com, simon.horman@...ronome.com,
roopa@...ulusnetworks.com, bridge@...ts.linux-foundation.org,
jhs@...atatu.com, dsahern@...il.com, xiyou.wangcong@...il.com,
johannes@...solutions.net, alexei.starovoitov@...il.com
Subject: Re: [Bridge] [PATCH v3 1/2] net: bridge: use mac_len in bridge
forwarding
Hi Zahari,
Sorry for reviewing this late.
On 2019/09/03 3:09, Zahari Doychev wrote:
...
> @@ -466,13 +466,14 @@ static bool __allowed_ingress(const struct net_bridge *br,
> /* Tagged frame */
> if (skb->vlan_proto != br->vlan_proto) {
> /* Protocol-mismatch, empty out vlan_tci for new tag */
> - skb_push(skb, ETH_HLEN);
> + skb_push(skb, skb->mac_len);
> skb = vlan_insert_tag_set_proto(skb, skb->vlan_proto,
> skb_vlan_tag_get(skb));
I think we should insert vlan at skb->data, i.e. mac_header + mac_len, while this
function inserts the tag at mac_header + ETH_HLEN which is not always the correct
offset.
> if (unlikely(!skb))
> return false;
>
> skb_pull(skb, ETH_HLEN);
Now skb->data is mac_header + ETH_HLEN which would be broken when mac_len is not
ETH_HLEN?
> + skb_reset_network_header(skb);
> skb_reset_mac_len(skb);
> *vid = 0;
> tagged = false;
>
Toshiaki Makita
Powered by blists - more mailing lists