BMC/Intel-BMC/linux.git/net/bridge/br_vlan.c, branch dev-4.4

bridge: vlan: Use rcu_dereference instead of rtnl_dereference

2015-11-02T21:27:39+00:00

br_should_learn() is protected by RCU and not by RTNL, so use correct flavor of nbp_vlan_group(). Fixes: 907b1e6e83ed ("bridge: vlan: use proper rcu for the vlgrp member") Signed-off-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Acked-by: Jiri Pirko Signed-off-by: David S. Miller

bridge: vlan: Use correct flag name in comment

2015-11-02T20:40:11+00:00

The flag used to indicate if a VLAN should be used for filtering - as opposed to context only - on the bridge itself (e.g. br0) is called 'brentry' and not 'brvlan'. Signed-off-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller

bridge: vlan: Prevent possible use-after-free

2015-11-02T20:40:10+00:00

When adding a port to a bridge we initialize VLAN filtering on it. We do not bail out in case an error occurred in nbp_vlan_init, as it can be used as a non VLAN filtering bridge. However, if VLAN filtering is required and an error occurred in nbp_vlan_init, we should set vlgrp to NULL, so that VLAN filtering functions (e.g. br_vlan_find, br_get_pvid) will know the struct is invalid and will not try to access it. Signed-off-by: Ido Schimmel Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller

bridge: vlan: move back vlan_flush

2015-10-13T11:57:58+00:00

Ido Schimmel reported a problem with switchdev devices because of the order change of del_nbp operations, more specifically the move of nbp_vlan_flush() which deletes all vlans and frees vlgrp after the rx_handler has been unregistered. So in order to fix this move vlan_flush back where it was and make it destroy the rhtable after NULLing vlgrp and waiting a grace period to make sure noone can see it. Reported-by: Ido Schimmel Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Signed-off-by: David S. Miller

bridge: vlan: drop unnecessary flush code

2015-10-13T11:57:56+00:00

As Ido Schimmel pointed out the vlan_vid_del() code in nbp_vlan_flush is unnecessary (and is actually a remnant of the old vlan code) so we can remove it. Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Signed-off-by: David S. Miller

bridge: vlan: use proper rcu for the vlgrp member

2015-10-13T11:57:52+00:00

The bridge and port's vlgrp member is already used in RCU way, currently we rely on the fact that it cannot disappear while the port exists but that is error-prone and we might miss places with improper locking (either RCU or RTNL must be held to walk the vlan_list). So make it official and use RCU for vlgrp to catch offenders. Introduce proper vlgrp accessors and use them consistently throughout the code. Signed-off-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Signed-off-by: David S. Miller

bridge: try switchdev op first in __vlan_vid_add/del

2015-10-13T02:35:20+00:00

Some drivers need to implement both switchdev vlan ops and vid_add/kill ndos. For that to work in bridge code, we need to try switchdev op first when adding/deleting vlan id. Signed-off-by: Jiri Pirko Signed-off-by: Ido Schimmel Acked-by: Scott Feldman Signed-off-by: David S. Miller

bridge: allow adding of fdb entries pointing to the bridge device

2015-10-12T12:11:58+00:00

This patch enables adding of fdb entries pointing to the bridge device. This can be used to propagate mac address of vlan interfaces configured on top of the vlan filtering bridge. Before: $bridge fdb add 44:38:39:00:27:9f dev bridge RTNETLINK answers: Invalid argument After: $bridge fdb add 44:38:39:00:27:9f dev bridge Signed-off-by: Roopa Prabhu Reviewed-by: Nikolay Aleksandrov Signed-off-by: David S. Miller

bridge: netlink: add support for default_pvid

2015-10-04T23:46:07+00:00

Add IFLA_BR_VLAN_DEFAULT_PVID to allow setting/getting bridge's default_pvid via netlink. Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller

bridge: vlan: use br_vlan_should_use to simplify __vlan_add/del

2015-10-04T23:43:50+00:00

The checks that lead to num_vlans change are always what br_vlan_should_use checks for, namely if the vlan is only a context or not and depending on that it's either not counted or counted as a real/used vlan respectively. Also give better explanation in br_vlan_should_use's comment. Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller