2019-05-26 23:55:01 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2005-04-16 15:20:36 -07:00
|
|
|
/*
|
|
|
|
* Generic parts
|
|
|
|
* Linux ethernet bridge
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Lennert Buytenhek <buytenh@gnu.org>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/netdevice.h>
|
|
|
|
#include <linux/etherdevice.h>
|
|
|
|
#include <linux/init.h>
|
2006-03-20 23:59:06 -07:00
|
|
|
#include <linux/llc.h>
|
|
|
|
#include <net/llc.h>
|
2008-07-05 21:25:56 -07:00
|
|
|
#include <net/stp.h>
|
2015-01-15 15:49:37 -07:00
|
|
|
#include <net/switchdev.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
#include "br_private.h"
|
|
|
|
|
2014-05-20 17:30:00 -07:00
|
|
|
/*
|
|
|
|
* Handle changes in state of network devices enslaved to a bridge.
|
|
|
|
*
|
|
|
|
* Note: don't care about up/down if bridge itself is down, because
|
|
|
|
* port state is checked when bridge is brought up.
|
|
|
|
*/
|
|
|
|
static int br_device_event(struct notifier_block *unused, unsigned long event, void *ptr)
|
|
|
|
{
|
2018-12-13 04:54:39 -07:00
|
|
|
struct netlink_ext_ack *extack = netdev_notifier_info_to_extack(ptr);
|
|
|
|
struct netdev_notifier_pre_changeaddr_info *prechaddr_info;
|
2014-05-20 17:30:00 -07:00
|
|
|
struct net_device *dev = netdev_notifier_info_to_dev(ptr);
|
|
|
|
struct net_bridge_port *p;
|
|
|
|
struct net_bridge *br;
|
2018-05-03 03:47:24 -07:00
|
|
|
bool notified = false;
|
2014-05-20 17:30:00 -07:00
|
|
|
bool changed_addr;
|
|
|
|
int err;
|
|
|
|
|
2021-10-16 04:21:36 -07:00
|
|
|
if (netif_is_bridge_master(dev)) {
|
2019-08-02 03:57:36 -07:00
|
|
|
err = br_vlan_bridge_event(dev, event, ptr);
|
|
|
|
if (err)
|
|
|
|
return notifier_from_errno(err);
|
|
|
|
|
2019-04-18 10:35:33 -07:00
|
|
|
if (event == NETDEV_REGISTER) {
|
|
|
|
/* register of bridge completed, add sysfs entries */
|
2020-12-11 05:29:21 -07:00
|
|
|
err = br_sysfs_addbr(dev);
|
|
|
|
if (err)
|
|
|
|
return notifier_from_errno(err);
|
|
|
|
|
2019-04-18 10:35:33 -07:00
|
|
|
return NOTIFY_DONE;
|
|
|
|
}
|
2014-05-20 17:30:00 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* not a port of a bridge */
|
|
|
|
p = br_port_get_rtnl(dev);
|
|
|
|
if (!p)
|
|
|
|
return NOTIFY_DONE;
|
|
|
|
|
|
|
|
br = p->br;
|
|
|
|
|
|
|
|
switch (event) {
|
|
|
|
case NETDEV_CHANGEMTU:
|
2018-03-30 03:46:19 -07:00
|
|
|
br_mtu_auto_adjust(br);
|
2014-05-20 17:30:00 -07:00
|
|
|
break;
|
|
|
|
|
2018-12-13 04:54:39 -07:00
|
|
|
case NETDEV_PRE_CHANGEADDR:
|
|
|
|
if (br->dev->addr_assign_type == NET_ADDR_SET)
|
|
|
|
break;
|
|
|
|
prechaddr_info = ptr;
|
|
|
|
err = dev_pre_changeaddr_notify(br->dev,
|
|
|
|
prechaddr_info->dev_addr,
|
|
|
|
extack);
|
|
|
|
if (err)
|
|
|
|
return notifier_from_errno(err);
|
|
|
|
break;
|
|
|
|
|
2014-05-20 17:30:00 -07:00
|
|
|
case NETDEV_CHANGEADDR:
|
|
|
|
spin_lock_bh(&br->lock);
|
|
|
|
br_fdb_changeaddr(p, dev->dev_addr);
|
|
|
|
changed_addr = br_stp_recalculate_bridge_id(br);
|
|
|
|
spin_unlock_bh(&br->lock);
|
|
|
|
|
|
|
|
if (changed_addr)
|
|
|
|
call_netdevice_notifiers(NETDEV_CHANGEADDR, br->dev);
|
|
|
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
case NETDEV_CHANGE:
|
2018-05-03 03:47:24 -07:00
|
|
|
br_port_carrier_check(p, ¬ified);
|
2014-05-20 17:30:00 -07:00
|
|
|
break;
|
|
|
|
|
|
|
|
case NETDEV_FEAT_CHANGE:
|
|
|
|
netdev_update_features(br->dev);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case NETDEV_DOWN:
|
|
|
|
spin_lock_bh(&br->lock);
|
2018-05-03 03:47:24 -07:00
|
|
|
if (br->dev->flags & IFF_UP) {
|
2014-05-20 17:30:00 -07:00
|
|
|
br_stp_disable_port(p);
|
2018-05-03 03:47:24 -07:00
|
|
|
notified = true;
|
|
|
|
}
|
2014-05-20 17:30:00 -07:00
|
|
|
spin_unlock_bh(&br->lock);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case NETDEV_UP:
|
|
|
|
if (netif_running(br->dev) && netif_oper_up(dev)) {
|
|
|
|
spin_lock_bh(&br->lock);
|
|
|
|
br_stp_enable_port(p);
|
2018-05-03 03:47:24 -07:00
|
|
|
notified = true;
|
2014-05-20 17:30:00 -07:00
|
|
|
spin_unlock_bh(&br->lock);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case NETDEV_UNREGISTER:
|
|
|
|
br_del_if(br, dev);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case NETDEV_CHANGENAME:
|
|
|
|
err = br_sysfs_renameif(p);
|
|
|
|
if (err)
|
|
|
|
return notifier_from_errno(err);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case NETDEV_PRE_TYPE_CHANGE:
|
2021-01-07 19:53:32 -07:00
|
|
|
/* Forbid underlying device to change its type. */
|
2014-05-20 17:30:00 -07:00
|
|
|
return NOTIFY_BAD;
|
|
|
|
|
|
|
|
case NETDEV_RESEND_IGMP:
|
|
|
|
/* Propagate to master device */
|
|
|
|
call_netdevice_notifiers(event, br->dev);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-04-22 02:33:19 -07:00
|
|
|
if (event != NETDEV_UNREGISTER)
|
|
|
|
br_vlan_port_event(p, event);
|
2019-04-18 10:35:33 -07:00
|
|
|
|
2014-05-20 17:30:00 -07:00
|
|
|
/* Events that may cause spanning tree to refresh */
|
2018-05-03 03:47:24 -07:00
|
|
|
if (!notified && (event == NETDEV_CHANGEADDR || event == NETDEV_UP ||
|
|
|
|
event == NETDEV_CHANGE || event == NETDEV_DOWN))
|
2017-11-01 03:18:13 -07:00
|
|
|
br_ifinfo_notify(RTM_NEWLINK, NULL, p);
|
2014-05-20 17:30:00 -07:00
|
|
|
|
|
|
|
return NOTIFY_DONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct notifier_block br_device_notifier = {
|
|
|
|
.notifier_call = br_device_event
|
|
|
|
};
|
|
|
|
|
2017-06-07 23:44:12 -07:00
|
|
|
/* called with RTNL or RCU */
|
2015-05-10 09:47:46 -07:00
|
|
|
static int br_switchdev_event(struct notifier_block *unused,
|
|
|
|
unsigned long event, void *ptr)
|
2015-01-15 15:49:37 -07:00
|
|
|
{
|
2015-05-10 09:47:46 -07:00
|
|
|
struct net_device *dev = switchdev_notifier_info_to_dev(ptr);
|
2015-01-15 15:49:37 -07:00
|
|
|
struct net_bridge_port *p;
|
|
|
|
struct net_bridge *br;
|
2015-05-10 09:47:46 -07:00
|
|
|
struct switchdev_notifier_fdb_info *fdb_info;
|
2015-01-15 15:49:37 -07:00
|
|
|
int err = NOTIFY_DONE;
|
|
|
|
|
2017-06-07 23:44:12 -07:00
|
|
|
p = br_port_get_rtnl_rcu(dev);
|
2015-01-15 15:49:37 -07:00
|
|
|
if (!p)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
br = p->br;
|
|
|
|
|
|
|
|
switch (event) {
|
2017-06-07 23:44:14 -07:00
|
|
|
case SWITCHDEV_FDB_ADD_TO_BRIDGE:
|
2015-01-15 15:49:37 -07:00
|
|
|
fdb_info = ptr;
|
|
|
|
err = br_fdb_external_learn_add(br, p, fdb_info->addr,
|
2022-11-08 03:47:08 -07:00
|
|
|
fdb_info->vid,
|
|
|
|
fdb_info->locked, false);
|
2017-06-07 23:44:15 -07:00
|
|
|
if (err) {
|
2015-01-15 15:49:37 -07:00
|
|
|
err = notifier_from_errno(err);
|
2017-06-07 23:44:15 -07:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
br_fdb_offloaded_set(br, p, fdb_info->addr,
|
2022-11-08 03:47:07 -07:00
|
|
|
fdb_info->vid, fdb_info->offloaded);
|
2015-01-15 15:49:37 -07:00
|
|
|
break;
|
2017-06-07 23:44:14 -07:00
|
|
|
case SWITCHDEV_FDB_DEL_TO_BRIDGE:
|
2015-01-15 15:49:37 -07:00
|
|
|
fdb_info = ptr;
|
|
|
|
err = br_fdb_external_learn_del(br, p, fdb_info->addr,
|
2018-05-03 05:43:53 -07:00
|
|
|
fdb_info->vid, false);
|
2015-01-15 15:49:37 -07:00
|
|
|
if (err)
|
|
|
|
err = notifier_from_errno(err);
|
|
|
|
break;
|
2017-06-07 23:44:15 -07:00
|
|
|
case SWITCHDEV_FDB_OFFLOADED:
|
|
|
|
fdb_info = ptr;
|
|
|
|
br_fdb_offloaded_set(br, p, fdb_info->addr,
|
2018-10-17 01:53:29 -07:00
|
|
|
fdb_info->vid, fdb_info->offloaded);
|
2017-06-07 23:44:15 -07:00
|
|
|
break;
|
2020-09-10 10:23:48 -07:00
|
|
|
case SWITCHDEV_FDB_FLUSH_TO_BRIDGE:
|
|
|
|
fdb_info = ptr;
|
|
|
|
/* Don't delete static entries */
|
|
|
|
br_fdb_delete_by_port(br, p, fdb_info->vid, 0);
|
|
|
|
break;
|
2015-01-15 15:49:37 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2015-05-10 09:47:46 -07:00
|
|
|
static struct notifier_block br_switchdev_notifier = {
|
|
|
|
.notifier_call = br_switchdev_event,
|
2015-01-15 15:49:37 -07:00
|
|
|
};
|
|
|
|
|
net: make switchdev_bridge_port_{,unoffload} loosely coupled with the bridge
With the introduction of explicit offloading API in switchdev in commit
2f5dc00f7a3e ("net: bridge: switchdev: let drivers inform which bridge
ports are offloaded"), we started having Ethernet switch drivers calling
directly into a function exported by net/bridge/br_switchdev.c, which is
a function exported by the bridge driver.
This means that drivers that did not have an explicit dependency on the
bridge before, like cpsw and am65-cpsw, now do - otherwise it is not
possible to call a symbol exported by a driver that can be built as
module unless you are a module too.
There was an attempt to solve the dependency issue in the form of commit
b0e81817629a ("net: build all switchdev drivers as modules when the
bridge is a module"). Grygorii Strashko, however, says about it:
| In my opinion, the problem is a bit bigger here than just fixing the
| build :(
|
| In case, of ^cpsw the switchdev mode is kinda optional and in many
| cases (especially for testing purposes, NFS) the multi-mac mode is
| still preferable mode.
|
| There were no such tight dependency between switchdev drivers and
| bridge core before and switchdev serviced as independent, notification
| based layer between them, so ^cpsw still can be "Y" and bridge can be
| "M". Now for mostly every kernel build configuration the CONFIG_BRIDGE
| will need to be set as "Y", or we will have to update drivers to
| support build with BRIDGE=n and maintain separate builds for
| networking vs non-networking testing. But is this enough? Wouldn't
| it cause 'chain reaction' required to add more and more "Y" options
| (like CONFIG_VLAN_8021Q)?
|
| PS. Just to be sure we on the same page - ARM builds will be forced
| (with this patch) to have CONFIG_TI_CPSW_SWITCHDEV=m and so all our
| automation testing will just fail with omap2plus_defconfig.
In the light of this, it would be desirable for some configurations to
avoid dependencies between switchdev drivers and the bridge, and have
the switchdev mode as completely optional within the driver.
Arnd Bergmann also tried to write a patch which better expressed the
build time dependency for Ethernet switch drivers where the switchdev
support is optional, like cpsw/am65-cpsw, and this made the drivers
follow the bridge (compile as module if the bridge is a module) only if
the optional switchdev support in the driver was enabled in the first
place:
https://patchwork.kernel.org/project/netdevbpf/patch/20210802144813.1152762-1-arnd@kernel.org/
but this still did not solve the fact that cpsw and am65-cpsw now must
be built as modules when the bridge is a module - it just expressed
correctly that optional dependency. But the new behavior is an apparent
regression from Grygorii's perspective.
So to support the use case where the Ethernet driver is built-in,
NET_SWITCHDEV (a bool option) is enabled, and the bridge is a module, we
need a framework that can handle the possible absence of the bridge from
the running system, i.e. runtime bloatware as opposed to build-time
bloatware.
Luckily we already have this framework, since switchdev has been using
it extensively. Events from the bridge side are transmitted to the
driver side using notifier chains - this was originally done so that
unrelated drivers could snoop for events emitted by the bridge towards
ports that are implemented by other drivers (think of a switch driver
with LAG offload that listens for switchdev events on a bonding/team
interface that it offloads).
There are also events which are transmitted from the driver side to the
bridge side, which again are modeled using notifiers.
SWITCHDEV_FDB_ADD_TO_BRIDGE is an example of this, and deals with
notifying the bridge that a MAC address has been dynamically learned.
So there is a precedent we can use for modeling the new framework.
The difference compared to SWITCHDEV_FDB_ADD_TO_BRIDGE is that the work
that the bridge needs to do when a port becomes offloaded is blocking in
its nature: replay VLANs, MDBs etc. The calling context is indeed
blocking (we are under rtnl_mutex), but the existing switchdev
notification chain that the bridge is subscribed to is only the atomic
one. So we need to subscribe the bridge to the blocking switchdev
notification chain too.
This patch:
- keeps the driver-side perception of the switchdev_bridge_port_{,un}offload
unchanged
- moves the implementation of switchdev_bridge_port_{,un}offload from
the bridge module into the switchdev module.
- makes everybody that is subscribed to the switchdev blocking notifier
chain "hear" offload & unoffload events
- makes the bridge driver subscribe and handle those events
- moves the bridge driver's handling of those events into 2 new
functions called br_switchdev_port_{,un}offload. These functions
contain in fact the core of the logic that was previously in
switchdev_bridge_port_{,un}offload, just that now we go through an
extra indirection layer to reach them.
Unlike all the other switchdev notification structures, the structure
used to carry the bridge port information, struct
switchdev_notifier_brport_info, does not contain a "bool handled".
This is because in the current usage pattern, we always know that a
switchdev bridge port offloading event will be handled by the bridge,
because the switchdev_bridge_port_offload() call was initiated by a
NETDEV_CHANGEUPPER event in the first place, where info->upper_dev is a
bridge. So if the bridge wasn't loaded, then the CHANGEUPPER event
couldn't have happened.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-03 13:34:08 -07:00
|
|
|
/* called under rtnl_mutex */
|
|
|
|
static int br_switchdev_blocking_event(struct notifier_block *nb,
|
|
|
|
unsigned long event, void *ptr)
|
|
|
|
{
|
|
|
|
struct netlink_ext_ack *extack = netdev_notifier_info_to_extack(ptr);
|
|
|
|
struct net_device *dev = switchdev_notifier_info_to_dev(ptr);
|
|
|
|
struct switchdev_notifier_brport_info *brport_info;
|
|
|
|
const struct switchdev_brport *b;
|
|
|
|
struct net_bridge_port *p;
|
|
|
|
int err = NOTIFY_DONE;
|
|
|
|
|
|
|
|
p = br_port_get_rtnl(dev);
|
|
|
|
if (!p)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
switch (event) {
|
|
|
|
case SWITCHDEV_BRPORT_OFFLOADED:
|
|
|
|
brport_info = ptr;
|
|
|
|
b = &brport_info->brport;
|
|
|
|
|
|
|
|
err = br_switchdev_port_offload(p, b->dev, b->ctx,
|
|
|
|
b->atomic_nb, b->blocking_nb,
|
|
|
|
b->tx_fwd_offload, extack);
|
|
|
|
err = notifier_from_errno(err);
|
|
|
|
break;
|
|
|
|
case SWITCHDEV_BRPORT_UNOFFLOADED:
|
|
|
|
brport_info = ptr;
|
|
|
|
b = &brport_info->brport;
|
|
|
|
|
|
|
|
br_switchdev_port_unoffload(p, b->ctx, b->atomic_nb,
|
|
|
|
b->blocking_nb);
|
|
|
|
break;
|
2023-07-19 04:01:17 -07:00
|
|
|
case SWITCHDEV_BRPORT_REPLAY:
|
|
|
|
brport_info = ptr;
|
|
|
|
b = &brport_info->brport;
|
|
|
|
|
|
|
|
err = br_switchdev_port_replay(p, b->dev, b->ctx, b->atomic_nb,
|
|
|
|
b->blocking_nb, extack);
|
|
|
|
err = notifier_from_errno(err);
|
|
|
|
break;
|
net: make switchdev_bridge_port_{,unoffload} loosely coupled with the bridge
With the introduction of explicit offloading API in switchdev in commit
2f5dc00f7a3e ("net: bridge: switchdev: let drivers inform which bridge
ports are offloaded"), we started having Ethernet switch drivers calling
directly into a function exported by net/bridge/br_switchdev.c, which is
a function exported by the bridge driver.
This means that drivers that did not have an explicit dependency on the
bridge before, like cpsw and am65-cpsw, now do - otherwise it is not
possible to call a symbol exported by a driver that can be built as
module unless you are a module too.
There was an attempt to solve the dependency issue in the form of commit
b0e81817629a ("net: build all switchdev drivers as modules when the
bridge is a module"). Grygorii Strashko, however, says about it:
| In my opinion, the problem is a bit bigger here than just fixing the
| build :(
|
| In case, of ^cpsw the switchdev mode is kinda optional and in many
| cases (especially for testing purposes, NFS) the multi-mac mode is
| still preferable mode.
|
| There were no such tight dependency between switchdev drivers and
| bridge core before and switchdev serviced as independent, notification
| based layer between them, so ^cpsw still can be "Y" and bridge can be
| "M". Now for mostly every kernel build configuration the CONFIG_BRIDGE
| will need to be set as "Y", or we will have to update drivers to
| support build with BRIDGE=n and maintain separate builds for
| networking vs non-networking testing. But is this enough? Wouldn't
| it cause 'chain reaction' required to add more and more "Y" options
| (like CONFIG_VLAN_8021Q)?
|
| PS. Just to be sure we on the same page - ARM builds will be forced
| (with this patch) to have CONFIG_TI_CPSW_SWITCHDEV=m and so all our
| automation testing will just fail with omap2plus_defconfig.
In the light of this, it would be desirable for some configurations to
avoid dependencies between switchdev drivers and the bridge, and have
the switchdev mode as completely optional within the driver.
Arnd Bergmann also tried to write a patch which better expressed the
build time dependency for Ethernet switch drivers where the switchdev
support is optional, like cpsw/am65-cpsw, and this made the drivers
follow the bridge (compile as module if the bridge is a module) only if
the optional switchdev support in the driver was enabled in the first
place:
https://patchwork.kernel.org/project/netdevbpf/patch/20210802144813.1152762-1-arnd@kernel.org/
but this still did not solve the fact that cpsw and am65-cpsw now must
be built as modules when the bridge is a module - it just expressed
correctly that optional dependency. But the new behavior is an apparent
regression from Grygorii's perspective.
So to support the use case where the Ethernet driver is built-in,
NET_SWITCHDEV (a bool option) is enabled, and the bridge is a module, we
need a framework that can handle the possible absence of the bridge from
the running system, i.e. runtime bloatware as opposed to build-time
bloatware.
Luckily we already have this framework, since switchdev has been using
it extensively. Events from the bridge side are transmitted to the
driver side using notifier chains - this was originally done so that
unrelated drivers could snoop for events emitted by the bridge towards
ports that are implemented by other drivers (think of a switch driver
with LAG offload that listens for switchdev events on a bonding/team
interface that it offloads).
There are also events which are transmitted from the driver side to the
bridge side, which again are modeled using notifiers.
SWITCHDEV_FDB_ADD_TO_BRIDGE is an example of this, and deals with
notifying the bridge that a MAC address has been dynamically learned.
So there is a precedent we can use for modeling the new framework.
The difference compared to SWITCHDEV_FDB_ADD_TO_BRIDGE is that the work
that the bridge needs to do when a port becomes offloaded is blocking in
its nature: replay VLANs, MDBs etc. The calling context is indeed
blocking (we are under rtnl_mutex), but the existing switchdev
notification chain that the bridge is subscribed to is only the atomic
one. So we need to subscribe the bridge to the blocking switchdev
notification chain too.
This patch:
- keeps the driver-side perception of the switchdev_bridge_port_{,un}offload
unchanged
- moves the implementation of switchdev_bridge_port_{,un}offload from
the bridge module into the switchdev module.
- makes everybody that is subscribed to the switchdev blocking notifier
chain "hear" offload & unoffload events
- makes the bridge driver subscribe and handle those events
- moves the bridge driver's handling of those events into 2 new
functions called br_switchdev_port_{,un}offload. These functions
contain in fact the core of the logic that was previously in
switchdev_bridge_port_{,un}offload, just that now we go through an
extra indirection layer to reach them.
Unlike all the other switchdev notification structures, the structure
used to carry the bridge port information, struct
switchdev_notifier_brport_info, does not contain a "bool handled".
This is because in the current usage pattern, we always know that a
switchdev bridge port offloading event will be handled by the bridge,
because the switchdev_bridge_port_offload() call was initiated by a
NETDEV_CHANGEUPPER event in the first place, where info->upper_dev is a
bridge. So if the bridge wasn't loaded, then the CHANGEUPPER event
couldn't have happened.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-03 13:34:08 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct notifier_block br_switchdev_blocking_notifier = {
|
|
|
|
.notifier_call = br_switchdev_blocking_event,
|
|
|
|
};
|
|
|
|
|
2018-11-23 19:34:20 -07:00
|
|
|
/* br_boolopt_toggle - change user-controlled boolean option
|
|
|
|
*
|
|
|
|
* @br: bridge device
|
|
|
|
* @opt: id of the option to change
|
|
|
|
* @on: new option value
|
|
|
|
* @extack: extack for error messages
|
|
|
|
*
|
|
|
|
* Changes the value of the respective boolean option to @on taking care of
|
|
|
|
* any internal option value mapping and configuration.
|
|
|
|
*/
|
|
|
|
int br_boolopt_toggle(struct net_bridge *br, enum br_boolopt_id opt, bool on,
|
|
|
|
struct netlink_ext_ack *extack)
|
|
|
|
{
|
2021-07-19 10:06:28 -07:00
|
|
|
int err = 0;
|
|
|
|
|
2018-11-23 19:34:20 -07:00
|
|
|
switch (opt) {
|
2018-11-23 19:34:21 -07:00
|
|
|
case BR_BOOLOPT_NO_LL_LEARN:
|
|
|
|
br_opt_toggle(br, BROPT_NO_LL_LEARN, on);
|
|
|
|
break;
|
2021-07-19 10:06:28 -07:00
|
|
|
case BR_BOOLOPT_MCAST_VLAN_SNOOPING:
|
|
|
|
err = br_multicast_toggle_vlan_snooping(br, on, extack);
|
|
|
|
break;
|
net: bridge: mst: Multiple Spanning Tree (MST) mode
Allow the user to switch from the current per-VLAN STP mode to an MST
mode.
Up to this point, per-VLAN STP states where always isolated from each
other. This is in contrast to the MSTP standard (802.1Q-2018, Clause
13.5), where VLANs are grouped into MST instances (MSTIs), and the
state is managed on a per-MSTI level, rather that at the per-VLAN
level.
Perhaps due to the prevalence of the standard, many switching ASICs
are built after the same model. Therefore, add a corresponding MST
mode to the bridge, which we can later add offloading support for in a
straight-forward way.
For now, all VLANs are fixed to MSTI 0, also called the Common
Spanning Tree (CST). That is, all VLANs will follow the port-global
state.
Upcoming changes will make this actually useful by allowing VLANs to
be mapped to arbitrary MSTIs and allow individual MSTI states to be
changed.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 08:08:43 -07:00
|
|
|
case BR_BOOLOPT_MST_ENABLE:
|
|
|
|
err = br_mst_set_enabled(br, on, extack);
|
|
|
|
break;
|
2018-11-23 19:34:20 -07:00
|
|
|
default:
|
|
|
|
/* shouldn't be called with unsupported options */
|
|
|
|
WARN_ON(1);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2021-07-19 10:06:28 -07:00
|
|
|
return err;
|
2018-11-23 19:34:20 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
int br_boolopt_get(const struct net_bridge *br, enum br_boolopt_id opt)
|
|
|
|
{
|
|
|
|
switch (opt) {
|
2018-11-23 19:34:21 -07:00
|
|
|
case BR_BOOLOPT_NO_LL_LEARN:
|
|
|
|
return br_opt_get(br, BROPT_NO_LL_LEARN);
|
2021-07-19 10:06:28 -07:00
|
|
|
case BR_BOOLOPT_MCAST_VLAN_SNOOPING:
|
|
|
|
return br_opt_get(br, BROPT_MCAST_VLAN_SNOOPING_ENABLED);
|
net: bridge: mst: Multiple Spanning Tree (MST) mode
Allow the user to switch from the current per-VLAN STP mode to an MST
mode.
Up to this point, per-VLAN STP states where always isolated from each
other. This is in contrast to the MSTP standard (802.1Q-2018, Clause
13.5), where VLANs are grouped into MST instances (MSTIs), and the
state is managed on a per-MSTI level, rather that at the per-VLAN
level.
Perhaps due to the prevalence of the standard, many switching ASICs
are built after the same model. Therefore, add a corresponding MST
mode to the bridge, which we can later add offloading support for in a
straight-forward way.
For now, all VLANs are fixed to MSTI 0, also called the Common
Spanning Tree (CST). That is, all VLANs will follow the port-global
state.
Upcoming changes will make this actually useful by allowing VLANs to
be mapped to arbitrary MSTIs and allow individual MSTI states to be
changed.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-16 08:08:43 -07:00
|
|
|
case BR_BOOLOPT_MST_ENABLE:
|
|
|
|
return br_opt_get(br, BROPT_MST_ENABLED);
|
2018-11-23 19:34:20 -07:00
|
|
|
default:
|
|
|
|
/* shouldn't be called with unsupported options */
|
|
|
|
WARN_ON(1);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int br_boolopt_multi_toggle(struct net_bridge *br,
|
|
|
|
struct br_boolopt_multi *bm,
|
|
|
|
struct netlink_ext_ack *extack)
|
|
|
|
{
|
|
|
|
unsigned long bitmap = bm->optmask;
|
|
|
|
int err = 0;
|
|
|
|
int opt_id;
|
|
|
|
|
|
|
|
for_each_set_bit(opt_id, &bitmap, BR_BOOLOPT_MAX) {
|
|
|
|
bool on = !!(bm->optval & BIT(opt_id));
|
|
|
|
|
|
|
|
err = br_boolopt_toggle(br, opt_id, on, extack);
|
|
|
|
if (err) {
|
|
|
|
br_debug(br, "boolopt multi-toggle error: option: %d current: %d new: %d error: %d\n",
|
|
|
|
opt_id, br_boolopt_get(br, opt_id), on, err);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
void br_boolopt_multi_get(const struct net_bridge *br,
|
|
|
|
struct br_boolopt_multi *bm)
|
|
|
|
{
|
|
|
|
u32 optval = 0;
|
|
|
|
int opt_id;
|
|
|
|
|
|
|
|
for (opt_id = 0; opt_id < BR_BOOLOPT_MAX; opt_id++)
|
|
|
|
optval |= (br_boolopt_get(br, opt_id) << opt_id);
|
|
|
|
|
|
|
|
bm->optval = optval;
|
2018-11-23 19:34:22 -07:00
|
|
|
bm->optmask = GENMASK((BR_BOOLOPT_MAX - 1), 0);
|
2018-11-23 19:34:20 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* private bridge options, controlled by the kernel */
|
2018-09-26 07:01:00 -07:00
|
|
|
void br_opt_toggle(struct net_bridge *br, enum net_bridge_opts opt, bool on)
|
|
|
|
{
|
|
|
|
bool cur = !!br_opt_get(br, opt);
|
|
|
|
|
|
|
|
br_debug(br, "toggle option: %d state: %d -> %d\n",
|
|
|
|
opt, cur, on);
|
|
|
|
|
|
|
|
if (cur == on)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (on)
|
|
|
|
set_bit(opt, &br->options);
|
|
|
|
else
|
|
|
|
clear_bit(opt, &br->options);
|
|
|
|
}
|
|
|
|
|
2024-02-06 07:43:11 -07:00
|
|
|
static void __net_exit br_net_exit_batch_rtnl(struct list_head *net_list,
|
|
|
|
struct list_head *dev_to_kill)
|
2014-01-10 14:58:47 -07:00
|
|
|
{
|
|
|
|
struct net_device *dev;
|
2022-02-18 00:01:50 -07:00
|
|
|
struct net *net;
|
|
|
|
|
2024-02-06 07:43:11 -07:00
|
|
|
ASSERT_RTNL();
|
2022-02-18 00:01:50 -07:00
|
|
|
list_for_each_entry(net, net_list, exit_list)
|
|
|
|
for_each_netdev(net, dev)
|
|
|
|
if (netif_is_bridge_master(dev))
|
2024-02-06 07:43:11 -07:00
|
|
|
br_dev_delete(dev, dev_to_kill);
|
2014-01-10 14:58:47 -07:00
|
|
|
}
|
2006-03-20 23:59:06 -07:00
|
|
|
|
2008-09-08 16:20:18 -07:00
|
|
|
static struct pernet_operations br_net_ops = {
|
2024-02-06 07:43:11 -07:00
|
|
|
.exit_batch_rtnl = br_net_exit_batch_rtnl,
|
2008-09-08 16:20:18 -07:00
|
|
|
};
|
|
|
|
|
2014-01-10 14:58:47 -07:00
|
|
|
static const struct stp_proto br_stp_proto = {
|
|
|
|
.rcv = br_stp_rcv,
|
|
|
|
};
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
static int __init br_init(void)
|
|
|
|
{
|
2006-05-25 15:59:33 -07:00
|
|
|
int err;
|
|
|
|
|
2019-12-09 11:31:43 -07:00
|
|
|
BUILD_BUG_ON(sizeof(struct br_input_skb_cb) > sizeof_field(struct sk_buff, cb));
|
2015-03-03 05:53:31 -07:00
|
|
|
|
2008-07-05 21:25:56 -07:00
|
|
|
err = stp_proto_register(&br_stp_proto);
|
|
|
|
if (err < 0) {
|
2010-05-10 02:31:09 -07:00
|
|
|
pr_err("bridge: can't register sap for STP\n");
|
2008-07-05 21:25:56 -07:00
|
|
|
return err;
|
2006-03-20 23:59:06 -07:00
|
|
|
}
|
|
|
|
|
2007-04-07 02:57:07 -07:00
|
|
|
err = br_fdb_init();
|
|
|
|
if (err)
|
2007-11-29 05:41:43 -07:00
|
|
|
goto err_out;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-09-08 16:20:18 -07:00
|
|
|
err = register_pernet_subsys(&br_net_ops);
|
2006-05-25 15:59:33 -07:00
|
|
|
if (err)
|
|
|
|
goto err_out1;
|
|
|
|
|
2014-09-18 02:29:03 -07:00
|
|
|
err = br_nf_core_init();
|
2006-05-25 15:59:33 -07:00
|
|
|
if (err)
|
|
|
|
goto err_out2;
|
|
|
|
|
2008-09-08 16:20:18 -07:00
|
|
|
err = register_netdevice_notifier(&br_device_notifier);
|
2007-03-22 11:59:03 -07:00
|
|
|
if (err)
|
|
|
|
goto err_out3;
|
|
|
|
|
2015-05-10 09:47:46 -07:00
|
|
|
err = register_switchdev_notifier(&br_switchdev_notifier);
|
2008-09-08 16:20:18 -07:00
|
|
|
if (err)
|
|
|
|
goto err_out4;
|
|
|
|
|
net: make switchdev_bridge_port_{,unoffload} loosely coupled with the bridge
With the introduction of explicit offloading API in switchdev in commit
2f5dc00f7a3e ("net: bridge: switchdev: let drivers inform which bridge
ports are offloaded"), we started having Ethernet switch drivers calling
directly into a function exported by net/bridge/br_switchdev.c, which is
a function exported by the bridge driver.
This means that drivers that did not have an explicit dependency on the
bridge before, like cpsw and am65-cpsw, now do - otherwise it is not
possible to call a symbol exported by a driver that can be built as
module unless you are a module too.
There was an attempt to solve the dependency issue in the form of commit
b0e81817629a ("net: build all switchdev drivers as modules when the
bridge is a module"). Grygorii Strashko, however, says about it:
| In my opinion, the problem is a bit bigger here than just fixing the
| build :(
|
| In case, of ^cpsw the switchdev mode is kinda optional and in many
| cases (especially for testing purposes, NFS) the multi-mac mode is
| still preferable mode.
|
| There were no such tight dependency between switchdev drivers and
| bridge core before and switchdev serviced as independent, notification
| based layer between them, so ^cpsw still can be "Y" and bridge can be
| "M". Now for mostly every kernel build configuration the CONFIG_BRIDGE
| will need to be set as "Y", or we will have to update drivers to
| support build with BRIDGE=n and maintain separate builds for
| networking vs non-networking testing. But is this enough? Wouldn't
| it cause 'chain reaction' required to add more and more "Y" options
| (like CONFIG_VLAN_8021Q)?
|
| PS. Just to be sure we on the same page - ARM builds will be forced
| (with this patch) to have CONFIG_TI_CPSW_SWITCHDEV=m and so all our
| automation testing will just fail with omap2plus_defconfig.
In the light of this, it would be desirable for some configurations to
avoid dependencies between switchdev drivers and the bridge, and have
the switchdev mode as completely optional within the driver.
Arnd Bergmann also tried to write a patch which better expressed the
build time dependency for Ethernet switch drivers where the switchdev
support is optional, like cpsw/am65-cpsw, and this made the drivers
follow the bridge (compile as module if the bridge is a module) only if
the optional switchdev support in the driver was enabled in the first
place:
https://patchwork.kernel.org/project/netdevbpf/patch/20210802144813.1152762-1-arnd@kernel.org/
but this still did not solve the fact that cpsw and am65-cpsw now must
be built as modules when the bridge is a module - it just expressed
correctly that optional dependency. But the new behavior is an apparent
regression from Grygorii's perspective.
So to support the use case where the Ethernet driver is built-in,
NET_SWITCHDEV (a bool option) is enabled, and the bridge is a module, we
need a framework that can handle the possible absence of the bridge from
the running system, i.e. runtime bloatware as opposed to build-time
bloatware.
Luckily we already have this framework, since switchdev has been using
it extensively. Events from the bridge side are transmitted to the
driver side using notifier chains - this was originally done so that
unrelated drivers could snoop for events emitted by the bridge towards
ports that are implemented by other drivers (think of a switch driver
with LAG offload that listens for switchdev events on a bonding/team
interface that it offloads).
There are also events which are transmitted from the driver side to the
bridge side, which again are modeled using notifiers.
SWITCHDEV_FDB_ADD_TO_BRIDGE is an example of this, and deals with
notifying the bridge that a MAC address has been dynamically learned.
So there is a precedent we can use for modeling the new framework.
The difference compared to SWITCHDEV_FDB_ADD_TO_BRIDGE is that the work
that the bridge needs to do when a port becomes offloaded is blocking in
its nature: replay VLANs, MDBs etc. The calling context is indeed
blocking (we are under rtnl_mutex), but the existing switchdev
notification chain that the bridge is subscribed to is only the atomic
one. So we need to subscribe the bridge to the blocking switchdev
notification chain too.
This patch:
- keeps the driver-side perception of the switchdev_bridge_port_{,un}offload
unchanged
- moves the implementation of switchdev_bridge_port_{,un}offload from
the bridge module into the switchdev module.
- makes everybody that is subscribed to the switchdev blocking notifier
chain "hear" offload & unoffload events
- makes the bridge driver subscribe and handle those events
- moves the bridge driver's handling of those events into 2 new
functions called br_switchdev_port_{,un}offload. These functions
contain in fact the core of the logic that was previously in
switchdev_bridge_port_{,un}offload, just that now we go through an
extra indirection layer to reach them.
Unlike all the other switchdev notification structures, the structure
used to carry the bridge port information, struct
switchdev_notifier_brport_info, does not contain a "bool handled".
This is because in the current usage pattern, we always know that a
switchdev bridge port offloading event will be handled by the bridge,
because the switchdev_bridge_port_offload() call was initiated by a
NETDEV_CHANGEUPPER event in the first place, where info->upper_dev is a
bridge. So if the bridge wasn't loaded, then the CHANGEUPPER event
couldn't have happened.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-03 13:34:08 -07:00
|
|
|
err = register_switchdev_blocking_notifier(&br_switchdev_blocking_notifier);
|
2015-01-15 15:49:37 -07:00
|
|
|
if (err)
|
|
|
|
goto err_out5;
|
|
|
|
|
net: make switchdev_bridge_port_{,unoffload} loosely coupled with the bridge
With the introduction of explicit offloading API in switchdev in commit
2f5dc00f7a3e ("net: bridge: switchdev: let drivers inform which bridge
ports are offloaded"), we started having Ethernet switch drivers calling
directly into a function exported by net/bridge/br_switchdev.c, which is
a function exported by the bridge driver.
This means that drivers that did not have an explicit dependency on the
bridge before, like cpsw and am65-cpsw, now do - otherwise it is not
possible to call a symbol exported by a driver that can be built as
module unless you are a module too.
There was an attempt to solve the dependency issue in the form of commit
b0e81817629a ("net: build all switchdev drivers as modules when the
bridge is a module"). Grygorii Strashko, however, says about it:
| In my opinion, the problem is a bit bigger here than just fixing the
| build :(
|
| In case, of ^cpsw the switchdev mode is kinda optional and in many
| cases (especially for testing purposes, NFS) the multi-mac mode is
| still preferable mode.
|
| There were no such tight dependency between switchdev drivers and
| bridge core before and switchdev serviced as independent, notification
| based layer between them, so ^cpsw still can be "Y" and bridge can be
| "M". Now for mostly every kernel build configuration the CONFIG_BRIDGE
| will need to be set as "Y", or we will have to update drivers to
| support build with BRIDGE=n and maintain separate builds for
| networking vs non-networking testing. But is this enough? Wouldn't
| it cause 'chain reaction' required to add more and more "Y" options
| (like CONFIG_VLAN_8021Q)?
|
| PS. Just to be sure we on the same page - ARM builds will be forced
| (with this patch) to have CONFIG_TI_CPSW_SWITCHDEV=m and so all our
| automation testing will just fail with omap2plus_defconfig.
In the light of this, it would be desirable for some configurations to
avoid dependencies between switchdev drivers and the bridge, and have
the switchdev mode as completely optional within the driver.
Arnd Bergmann also tried to write a patch which better expressed the
build time dependency for Ethernet switch drivers where the switchdev
support is optional, like cpsw/am65-cpsw, and this made the drivers
follow the bridge (compile as module if the bridge is a module) only if
the optional switchdev support in the driver was enabled in the first
place:
https://patchwork.kernel.org/project/netdevbpf/patch/20210802144813.1152762-1-arnd@kernel.org/
but this still did not solve the fact that cpsw and am65-cpsw now must
be built as modules when the bridge is a module - it just expressed
correctly that optional dependency. But the new behavior is an apparent
regression from Grygorii's perspective.
So to support the use case where the Ethernet driver is built-in,
NET_SWITCHDEV (a bool option) is enabled, and the bridge is a module, we
need a framework that can handle the possible absence of the bridge from
the running system, i.e. runtime bloatware as opposed to build-time
bloatware.
Luckily we already have this framework, since switchdev has been using
it extensively. Events from the bridge side are transmitted to the
driver side using notifier chains - this was originally done so that
unrelated drivers could snoop for events emitted by the bridge towards
ports that are implemented by other drivers (think of a switch driver
with LAG offload that listens for switchdev events on a bonding/team
interface that it offloads).
There are also events which are transmitted from the driver side to the
bridge side, which again are modeled using notifiers.
SWITCHDEV_FDB_ADD_TO_BRIDGE is an example of this, and deals with
notifying the bridge that a MAC address has been dynamically learned.
So there is a precedent we can use for modeling the new framework.
The difference compared to SWITCHDEV_FDB_ADD_TO_BRIDGE is that the work
that the bridge needs to do when a port becomes offloaded is blocking in
its nature: replay VLANs, MDBs etc. The calling context is indeed
blocking (we are under rtnl_mutex), but the existing switchdev
notification chain that the bridge is subscribed to is only the atomic
one. So we need to subscribe the bridge to the blocking switchdev
notification chain too.
This patch:
- keeps the driver-side perception of the switchdev_bridge_port_{,un}offload
unchanged
- moves the implementation of switchdev_bridge_port_{,un}offload from
the bridge module into the switchdev module.
- makes everybody that is subscribed to the switchdev blocking notifier
chain "hear" offload & unoffload events
- makes the bridge driver subscribe and handle those events
- moves the bridge driver's handling of those events into 2 new
functions called br_switchdev_port_{,un}offload. These functions
contain in fact the core of the logic that was previously in
switchdev_bridge_port_{,un}offload, just that now we go through an
extra indirection layer to reach them.
Unlike all the other switchdev notification structures, the structure
used to carry the bridge port information, struct
switchdev_notifier_brport_info, does not contain a "bool handled".
This is because in the current usage pattern, we always know that a
switchdev bridge port offloading event will be handled by the bridge,
because the switchdev_bridge_port_offload() call was initiated by a
NETDEV_CHANGEUPPER event in the first place, where info->upper_dev is a
bridge. So if the bridge wasn't loaded, then the CHANGEUPPER event
couldn't have happened.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-03 13:34:08 -07:00
|
|
|
err = br_netlink_init();
|
|
|
|
if (err)
|
|
|
|
goto err_out6;
|
|
|
|
|
2021-07-27 06:45:16 -07:00
|
|
|
brioctl_set(br_ioctl_stub);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-12-11 19:58:25 -07:00
|
|
|
#if IS_ENABLED(CONFIG_ATM_LANE)
|
2009-06-04 22:35:28 -07:00
|
|
|
br_fdb_test_addr_hook = br_fdb_test_addr;
|
|
|
|
#endif
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2016-09-28 15:05:28 -07:00
|
|
|
#if IS_MODULE(CONFIG_BRIDGE_NETFILTER)
|
|
|
|
pr_info("bridge: filtering via arp/ip/ip6tables is no longer available "
|
|
|
|
"by default. Update your scripts to load br_netfilter if you "
|
2014-09-18 02:29:03 -07:00
|
|
|
"need this.\n");
|
2016-09-28 15:05:28 -07:00
|
|
|
#endif
|
2014-09-18 02:29:03 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
return 0;
|
2014-09-18 02:29:03 -07:00
|
|
|
|
net: make switchdev_bridge_port_{,unoffload} loosely coupled with the bridge
With the introduction of explicit offloading API in switchdev in commit
2f5dc00f7a3e ("net: bridge: switchdev: let drivers inform which bridge
ports are offloaded"), we started having Ethernet switch drivers calling
directly into a function exported by net/bridge/br_switchdev.c, which is
a function exported by the bridge driver.
This means that drivers that did not have an explicit dependency on the
bridge before, like cpsw and am65-cpsw, now do - otherwise it is not
possible to call a symbol exported by a driver that can be built as
module unless you are a module too.
There was an attempt to solve the dependency issue in the form of commit
b0e81817629a ("net: build all switchdev drivers as modules when the
bridge is a module"). Grygorii Strashko, however, says about it:
| In my opinion, the problem is a bit bigger here than just fixing the
| build :(
|
| In case, of ^cpsw the switchdev mode is kinda optional and in many
| cases (especially for testing purposes, NFS) the multi-mac mode is
| still preferable mode.
|
| There were no such tight dependency between switchdev drivers and
| bridge core before and switchdev serviced as independent, notification
| based layer between them, so ^cpsw still can be "Y" and bridge can be
| "M". Now for mostly every kernel build configuration the CONFIG_BRIDGE
| will need to be set as "Y", or we will have to update drivers to
| support build with BRIDGE=n and maintain separate builds for
| networking vs non-networking testing. But is this enough? Wouldn't
| it cause 'chain reaction' required to add more and more "Y" options
| (like CONFIG_VLAN_8021Q)?
|
| PS. Just to be sure we on the same page - ARM builds will be forced
| (with this patch) to have CONFIG_TI_CPSW_SWITCHDEV=m and so all our
| automation testing will just fail with omap2plus_defconfig.
In the light of this, it would be desirable for some configurations to
avoid dependencies between switchdev drivers and the bridge, and have
the switchdev mode as completely optional within the driver.
Arnd Bergmann also tried to write a patch which better expressed the
build time dependency for Ethernet switch drivers where the switchdev
support is optional, like cpsw/am65-cpsw, and this made the drivers
follow the bridge (compile as module if the bridge is a module) only if
the optional switchdev support in the driver was enabled in the first
place:
https://patchwork.kernel.org/project/netdevbpf/patch/20210802144813.1152762-1-arnd@kernel.org/
but this still did not solve the fact that cpsw and am65-cpsw now must
be built as modules when the bridge is a module - it just expressed
correctly that optional dependency. But the new behavior is an apparent
regression from Grygorii's perspective.
So to support the use case where the Ethernet driver is built-in,
NET_SWITCHDEV (a bool option) is enabled, and the bridge is a module, we
need a framework that can handle the possible absence of the bridge from
the running system, i.e. runtime bloatware as opposed to build-time
bloatware.
Luckily we already have this framework, since switchdev has been using
it extensively. Events from the bridge side are transmitted to the
driver side using notifier chains - this was originally done so that
unrelated drivers could snoop for events emitted by the bridge towards
ports that are implemented by other drivers (think of a switch driver
with LAG offload that listens for switchdev events on a bonding/team
interface that it offloads).
There are also events which are transmitted from the driver side to the
bridge side, which again are modeled using notifiers.
SWITCHDEV_FDB_ADD_TO_BRIDGE is an example of this, and deals with
notifying the bridge that a MAC address has been dynamically learned.
So there is a precedent we can use for modeling the new framework.
The difference compared to SWITCHDEV_FDB_ADD_TO_BRIDGE is that the work
that the bridge needs to do when a port becomes offloaded is blocking in
its nature: replay VLANs, MDBs etc. The calling context is indeed
blocking (we are under rtnl_mutex), but the existing switchdev
notification chain that the bridge is subscribed to is only the atomic
one. So we need to subscribe the bridge to the blocking switchdev
notification chain too.
This patch:
- keeps the driver-side perception of the switchdev_bridge_port_{,un}offload
unchanged
- moves the implementation of switchdev_bridge_port_{,un}offload from
the bridge module into the switchdev module.
- makes everybody that is subscribed to the switchdev blocking notifier
chain "hear" offload & unoffload events
- makes the bridge driver subscribe and handle those events
- moves the bridge driver's handling of those events into 2 new
functions called br_switchdev_port_{,un}offload. These functions
contain in fact the core of the logic that was previously in
switchdev_bridge_port_{,un}offload, just that now we go through an
extra indirection layer to reach them.
Unlike all the other switchdev notification structures, the structure
used to carry the bridge port information, struct
switchdev_notifier_brport_info, does not contain a "bool handled".
This is because in the current usage pattern, we always know that a
switchdev bridge port offloading event will be handled by the bridge,
because the switchdev_bridge_port_offload() call was initiated by a
NETDEV_CHANGEUPPER event in the first place, where info->upper_dev is a
bridge. So if the bridge wasn't loaded, then the CHANGEUPPER event
couldn't have happened.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-03 13:34:08 -07:00
|
|
|
err_out6:
|
|
|
|
unregister_switchdev_blocking_notifier(&br_switchdev_blocking_notifier);
|
2015-01-15 15:49:37 -07:00
|
|
|
err_out5:
|
2015-05-10 09:47:46 -07:00
|
|
|
unregister_switchdev_notifier(&br_switchdev_notifier);
|
2008-09-08 16:20:18 -07:00
|
|
|
err_out4:
|
2007-03-22 11:59:03 -07:00
|
|
|
unregister_netdevice_notifier(&br_device_notifier);
|
2008-09-08 16:20:18 -07:00
|
|
|
err_out3:
|
2014-09-18 02:29:03 -07:00
|
|
|
br_nf_core_fini();
|
2008-09-08 16:20:18 -07:00
|
|
|
err_out2:
|
|
|
|
unregister_pernet_subsys(&br_net_ops);
|
2006-05-25 15:59:33 -07:00
|
|
|
err_out1:
|
2007-11-29 05:41:43 -07:00
|
|
|
br_fdb_fini();
|
|
|
|
err_out:
|
2008-07-05 21:25:56 -07:00
|
|
|
stp_proto_unregister(&br_stp_proto);
|
2006-05-25 15:59:33 -07:00
|
|
|
return err;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit br_deinit(void)
|
|
|
|
{
|
2008-07-05 21:25:56 -07:00
|
|
|
stp_proto_unregister(&br_stp_proto);
|
2006-05-25 16:00:12 -07:00
|
|
|
br_netlink_fini();
|
net: make switchdev_bridge_port_{,unoffload} loosely coupled with the bridge
With the introduction of explicit offloading API in switchdev in commit
2f5dc00f7a3e ("net: bridge: switchdev: let drivers inform which bridge
ports are offloaded"), we started having Ethernet switch drivers calling
directly into a function exported by net/bridge/br_switchdev.c, which is
a function exported by the bridge driver.
This means that drivers that did not have an explicit dependency on the
bridge before, like cpsw and am65-cpsw, now do - otherwise it is not
possible to call a symbol exported by a driver that can be built as
module unless you are a module too.
There was an attempt to solve the dependency issue in the form of commit
b0e81817629a ("net: build all switchdev drivers as modules when the
bridge is a module"). Grygorii Strashko, however, says about it:
| In my opinion, the problem is a bit bigger here than just fixing the
| build :(
|
| In case, of ^cpsw the switchdev mode is kinda optional and in many
| cases (especially for testing purposes, NFS) the multi-mac mode is
| still preferable mode.
|
| There were no such tight dependency between switchdev drivers and
| bridge core before and switchdev serviced as independent, notification
| based layer between them, so ^cpsw still can be "Y" and bridge can be
| "M". Now for mostly every kernel build configuration the CONFIG_BRIDGE
| will need to be set as "Y", or we will have to update drivers to
| support build with BRIDGE=n and maintain separate builds for
| networking vs non-networking testing. But is this enough? Wouldn't
| it cause 'chain reaction' required to add more and more "Y" options
| (like CONFIG_VLAN_8021Q)?
|
| PS. Just to be sure we on the same page - ARM builds will be forced
| (with this patch) to have CONFIG_TI_CPSW_SWITCHDEV=m and so all our
| automation testing will just fail with omap2plus_defconfig.
In the light of this, it would be desirable for some configurations to
avoid dependencies between switchdev drivers and the bridge, and have
the switchdev mode as completely optional within the driver.
Arnd Bergmann also tried to write a patch which better expressed the
build time dependency for Ethernet switch drivers where the switchdev
support is optional, like cpsw/am65-cpsw, and this made the drivers
follow the bridge (compile as module if the bridge is a module) only if
the optional switchdev support in the driver was enabled in the first
place:
https://patchwork.kernel.org/project/netdevbpf/patch/20210802144813.1152762-1-arnd@kernel.org/
but this still did not solve the fact that cpsw and am65-cpsw now must
be built as modules when the bridge is a module - it just expressed
correctly that optional dependency. But the new behavior is an apparent
regression from Grygorii's perspective.
So to support the use case where the Ethernet driver is built-in,
NET_SWITCHDEV (a bool option) is enabled, and the bridge is a module, we
need a framework that can handle the possible absence of the bridge from
the running system, i.e. runtime bloatware as opposed to build-time
bloatware.
Luckily we already have this framework, since switchdev has been using
it extensively. Events from the bridge side are transmitted to the
driver side using notifier chains - this was originally done so that
unrelated drivers could snoop for events emitted by the bridge towards
ports that are implemented by other drivers (think of a switch driver
with LAG offload that listens for switchdev events on a bonding/team
interface that it offloads).
There are also events which are transmitted from the driver side to the
bridge side, which again are modeled using notifiers.
SWITCHDEV_FDB_ADD_TO_BRIDGE is an example of this, and deals with
notifying the bridge that a MAC address has been dynamically learned.
So there is a precedent we can use for modeling the new framework.
The difference compared to SWITCHDEV_FDB_ADD_TO_BRIDGE is that the work
that the bridge needs to do when a port becomes offloaded is blocking in
its nature: replay VLANs, MDBs etc. The calling context is indeed
blocking (we are under rtnl_mutex), but the existing switchdev
notification chain that the bridge is subscribed to is only the atomic
one. So we need to subscribe the bridge to the blocking switchdev
notification chain too.
This patch:
- keeps the driver-side perception of the switchdev_bridge_port_{,un}offload
unchanged
- moves the implementation of switchdev_bridge_port_{,un}offload from
the bridge module into the switchdev module.
- makes everybody that is subscribed to the switchdev blocking notifier
chain "hear" offload & unoffload events
- makes the bridge driver subscribe and handle those events
- moves the bridge driver's handling of those events into 2 new
functions called br_switchdev_port_{,un}offload. These functions
contain in fact the core of the logic that was previously in
switchdev_bridge_port_{,un}offload, just that now we go through an
extra indirection layer to reach them.
Unlike all the other switchdev notification structures, the structure
used to carry the bridge port information, struct
switchdev_notifier_brport_info, does not contain a "bool handled".
This is because in the current usage pattern, we always know that a
switchdev bridge port offloading event will be handled by the bridge,
because the switchdev_bridge_port_offload() call was initiated by a
NETDEV_CHANGEUPPER event in the first place, where info->upper_dev is a
bridge. So if the bridge wasn't loaded, then the CHANGEUPPER event
couldn't have happened.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-08-03 13:34:08 -07:00
|
|
|
unregister_switchdev_blocking_notifier(&br_switchdev_blocking_notifier);
|
2015-05-10 09:47:46 -07:00
|
|
|
unregister_switchdev_notifier(&br_switchdev_notifier);
|
2005-04-16 15:20:36 -07:00
|
|
|
unregister_netdevice_notifier(&br_device_notifier);
|
|
|
|
brioctl_set(NULL);
|
2008-09-08 16:20:18 -07:00
|
|
|
unregister_pernet_subsys(&br_net_ops);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-06-26 03:45:48 -07:00
|
|
|
rcu_barrier(); /* Wait for completion of call_rcu()'s */
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-09-18 02:29:03 -07:00
|
|
|
br_nf_core_fini();
|
2011-12-11 19:58:25 -07:00
|
|
|
#if IS_ENABLED(CONFIG_ATM_LANE)
|
2009-06-04 22:35:28 -07:00
|
|
|
br_fdb_test_addr_hook = NULL;
|
|
|
|
#endif
|
2005-04-16 15:20:36 -07:00
|
|
|
br_fdb_fini();
|
|
|
|
}
|
|
|
|
|
|
|
|
module_init(br_init)
|
|
|
|
module_exit(br_deinit)
|
|
|
|
MODULE_LICENSE("GPL");
|
2005-12-21 20:01:30 -07:00
|
|
|
MODULE_VERSION(BR_VERSION);
|
2011-04-04 07:03:32 -07:00
|
|
|
MODULE_ALIAS_RTNL_LINK("bridge");
|
2023-10-27 03:05:49 -07:00
|
|
|
MODULE_DESCRIPTION("Ethernet bridge driver");
|