[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5415A9AC.1020400@gmail.com>
Date: Sun, 14 Sep 2014 23:43:56 +0900
From: Toshiaki Makita <toshiaki.makita1@...il.com>
To: Vladislav Yasevich <vyasevich@...il.com>, netdev@...r.kernel.org
CC: shemminger@...tta.com,
Toshiaki Makita <makita.toshiaki@....ntt.co.jp>,
Vladislav Yasevich <vyasevic@...hat.com>
Subject: Re: [PATCH 1/2] bridge: Check if vlan filtering is enabled only once.
(14/09/13 (土) 5:26), Vladislav Yasevich wrote:
> The bridge code checks if vlan filtering is enabled on both
> ingress and egress. When the state flip happens, it
> is possible for the bridge to currently be forwarding packets
> and forwarding behavior becomes non-deterministic. Bridge
> may drop packets on some interfaces, but not others.
>
> This patch solves this by caching the filtered state of the
> packet into skb_cb on ingress. The skb_cb is guaranteed to
> not be over-written between the time packet entres bridge
> forwarding path and the time it leaves it. On egress, we
> can then check the cached state to see if we need to
> apply filtering information.
...
> @@ -270,7 +275,8 @@ bool br_should_learn(struct net_bridge_port *p, struct sk_buff *skb, u16 *vid)
> struct net_bridge *br = p->br;
> struct net_port_vlans *v;
>
> - if (!br->vlan_enabled)
> + /* If filtering was disabled at input, let it pass. */
> + if (!BR_INPUT_SKB_CB(skb)->vlan_filtered)
> return true;
>
> v = rcu_dereference(p->vlan_info);
>
I'm afraid br_should_learn() is not called after calling
br_allowed_ingress(), so vlan_filtered doesn't seem to be initialized at
this point.
Thanks,
Toshiaki Makita
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists