* [patch net-next v2 08/19] mlxsw: spectrum_switchdev: Add support for querying supported bridge flags
From: Jiri Pirko @ 2017-06-08 6:44 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, arkadis, mlxsw, roopa, stephen, ivecera, nikolay
In-Reply-To: <20170608064428.4785-1-jiri@resnulli.us>
From: Arkadi Sharshevsky <arkadis@mellanox.com>
Add support for querying supported bridge flags.
Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index eb88b72..0333493 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -456,6 +456,9 @@ static int mlxsw_sp_port_attr_get(struct net_device *dev,
mlxsw_sp_port_bridge_flags_get(mlxsw_sp->bridge, attr->orig_dev,
&attr->u.brport_flags);
break;
+ case SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT:
+ attr->u.brport_flags_support = BR_LEARNING | BR_FLOOD;
+ break;
default:
return -EOPNOTSUPP;
}
--
2.9.3
^ permalink raw reply related
* [patch net-next v2 07/19] mlxsw: spectrum: Remove support for bridge FDB learning sync
From: Jiri Pirko @ 2017-06-08 6:44 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, arkadis, mlxsw, roopa, stephen, ivecera, nikolay
In-Reply-To: <20170608064428.4785-1-jiri@resnulli.us>
From: Arkadi Sharshevsky <arkadis@mellanox.com>
Currently the mlxsw driver supports an option for disabling syncing
the hardware learned FDBs with the software bridge. This behavior
breaks the bridge offload model and thus it is removed.
Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
.../net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 0111a77..eb88b72 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -1857,19 +1857,17 @@ void mlxsw_sp_port_bridge_leave(struct mlxsw_sp_port *mlxsw_sp_port,
mlxsw_sp_bridge_port_put(mlxsw_sp->bridge, bridge_port);
}
-static void mlxsw_sp_fdb_call_notifiers(bool learning_sync, bool adding,
+static void mlxsw_sp_fdb_call_notifiers(bool adding,
char *mac, u16 vid,
struct net_device *dev)
{
struct switchdev_notifier_fdb_info info;
unsigned long notifier_type;
- if (learning_sync) {
- info.addr = mac;
- info.vid = vid;
- notifier_type = adding ? SWITCHDEV_FDB_ADD_TO_BRIDGE : SWITCHDEV_FDB_DEL_TO_BRIDGE;
- call_switchdev_notifiers(notifier_type, dev, &info.info);
- }
+ info.addr = mac;
+ info.vid = vid;
+ notifier_type = adding ? SWITCHDEV_FDB_ADD_TO_BRIDGE : SWITCHDEV_FDB_DEL_TO_BRIDGE;
+ call_switchdev_notifiers(notifier_type, dev, &info.info);
}
static void mlxsw_sp_fdb_notify_mac_process(struct mlxsw_sp *mlxsw_sp,
@@ -1918,8 +1916,8 @@ static void mlxsw_sp_fdb_notify_mac_process(struct mlxsw_sp *mlxsw_sp,
if (!do_notification)
return;
- mlxsw_sp_fdb_call_notifiers(bridge_port->flags & BR_LEARNING_SYNC,
- adding, mac, vid, bridge_port->dev);
+ mlxsw_sp_fdb_call_notifiers(adding, mac, vid, bridge_port->dev);
+
return;
just_remove:
@@ -1976,8 +1974,8 @@ static void mlxsw_sp_fdb_notify_mac_lag_process(struct mlxsw_sp *mlxsw_sp,
if (!do_notification)
return;
- mlxsw_sp_fdb_call_notifiers(bridge_port->flags & BR_LEARNING_SYNC,
- adding, mac, vid, bridge_port->dev);
+ mlxsw_sp_fdb_call_notifiers(adding, mac, vid, bridge_port->dev);
+
return;
just_remove:
--
2.9.3
^ permalink raw reply related
* [patch net-next v2 06/19] net: bridge: Receive notification about successful FDB offload
From: Jiri Pirko @ 2017-06-08 6:44 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, arkadis, mlxsw, roopa, stephen, ivecera, nikolay
In-Reply-To: <20170608064428.4785-1-jiri@resnulli.us>
From: Arkadi Sharshevsky <arkadis@mellanox.com>
When a new static FDB is added to the bridge a notification is sent to
the driver for offload. In case of successful offload the driver should
notify the bridge back, which in turn should mark the FDB as offloaded.
Currently, externally learned is equivalent for being offloaded which is
not correct due to the fact that FDBs which are added from user-space are
also marked as externally learned. In order to specify if an FDB was
successfully offloaded a new flag is introduced.
Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
include/net/switchdev.h | 1 +
include/uapi/linux/neighbour.h | 1 +
net/bridge/br.c | 11 ++++++++++-
net/bridge/br_fdb.c | 22 +++++++++++++++++++++-
net/bridge/br_private.h | 5 ++++-
5 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index 8165ed9..c784a6a 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -159,6 +159,7 @@ enum switchdev_notifier_type {
SWITCHDEV_FDB_DEL_TO_BRIDGE,
SWITCHDEV_FDB_ADD_TO_DEVICE,
SWITCHDEV_FDB_DEL_TO_DEVICE,
+ SWITCHDEV_FDB_OFFLOADED,
};
struct switchdev_notifier_info {
diff --git a/include/uapi/linux/neighbour.h b/include/uapi/linux/neighbour.h
index f3d16db..3199d28 100644
--- a/include/uapi/linux/neighbour.h
+++ b/include/uapi/linux/neighbour.h
@@ -41,6 +41,7 @@ enum {
#define NTF_MASTER 0x04
#define NTF_PROXY 0x08 /* == ATF_PUBL */
#define NTF_EXT_LEARNED 0x10
+#define NTF_OFFLOADED 0x20
#define NTF_ROUTER 0x80
/*
diff --git a/net/bridge/br.c b/net/bridge/br.c
index 96d209c..1407d1b 100644
--- a/net/bridge/br.c
+++ b/net/bridge/br.c
@@ -142,8 +142,12 @@ static int br_switchdev_event(struct notifier_block *unused,
fdb_info = ptr;
err = br_fdb_external_learn_add(br, p, fdb_info->addr,
fdb_info->vid);
- if (err)
+ if (err) {
err = notifier_from_errno(err);
+ break;
+ }
+ br_fdb_offloaded_set(br, p, fdb_info->addr,
+ fdb_info->vid);
break;
case SWITCHDEV_FDB_DEL_TO_BRIDGE:
fdb_info = ptr;
@@ -152,6 +156,11 @@ static int br_switchdev_event(struct notifier_block *unused,
if (err)
err = notifier_from_errno(err);
break;
+ case SWITCHDEV_FDB_OFFLOADED:
+ fdb_info = ptr;
+ br_fdb_offloaded_set(br, p, fdb_info->addr,
+ fdb_info->vid);
+ break;
}
out:
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 26a1dae..fef7872 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -511,6 +511,7 @@ static struct net_bridge_fdb_entry *fdb_create(struct hlist_head *head,
fdb->is_static = is_static;
fdb->added_by_user = 0;
fdb->added_by_external_learn = 0;
+ fdb->offloaded = 0;
fdb->updated = fdb->used = jiffies;
hlist_add_head_rcu(&fdb->hlist, head);
}
@@ -647,11 +648,16 @@ static int fdb_fill_info(struct sk_buff *skb, const struct net_bridge *br,
ndm->ndm_family = AF_BRIDGE;
ndm->ndm_pad1 = 0;
ndm->ndm_pad2 = 0;
- ndm->ndm_flags = fdb->added_by_external_learn ? NTF_EXT_LEARNED : 0;
+ ndm->ndm_flags = 0;
ndm->ndm_type = 0;
ndm->ndm_ifindex = fdb->dst ? fdb->dst->dev->ifindex : br->dev->ifindex;
ndm->ndm_state = fdb_to_nud(br, fdb);
+ if (fdb->offloaded)
+ ndm->ndm_flags |= NTF_OFFLOADED;
+ if (fdb->added_by_external_learn)
+ ndm->ndm_flags |= NTF_EXT_LEARNED;
+
if (nla_put(skb, NDA_LLADDR, ETH_ALEN, &fdb->addr))
goto nla_put_failure;
if (nla_put_u32(skb, NDA_MASTER, br->dev->ifindex))
@@ -1123,3 +1129,17 @@ int br_fdb_external_learn_del(struct net_bridge *br, struct net_bridge_port *p,
return err;
}
+
+void br_fdb_offloaded_set(struct net_bridge *br, struct net_bridge_port *p,
+ const unsigned char *addr, u16 vid)
+{
+ struct net_bridge_fdb_entry *fdb;
+
+ spin_lock_bh(&br->hash_lock);
+
+ fdb = br_fdb_find(br, addr, vid);
+ if (fdb)
+ fdb->offloaded = 1;
+
+ spin_unlock_bh(&br->hash_lock);
+}
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 98410ea..c18682f 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -169,7 +169,8 @@ struct net_bridge_fdb_entry {
unsigned char is_local:1,
is_static:1,
added_by_user:1,
- added_by_external_learn:1;
+ added_by_external_learn:1,
+ offloaded:1;
/* write-heavy members should not affect lookups */
unsigned long updated ____cacheline_aligned_in_smp;
@@ -536,6 +537,8 @@ int br_fdb_external_learn_add(struct net_bridge *br, struct net_bridge_port *p,
const unsigned char *addr, u16 vid);
int br_fdb_external_learn_del(struct net_bridge *br, struct net_bridge_port *p,
const unsigned char *addr, u16 vid);
+void br_fdb_offloaded_set(struct net_bridge *br, struct net_bridge_port *p,
+ const unsigned char *addr, u16 vid);
/* br_forward.c */
enum br_pkt_type {
--
2.9.3
^ permalink raw reply related
* [patch net-next v2 04/19] net: switchdev: Change notifier chain to be atomic
From: Jiri Pirko @ 2017-06-08 6:44 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, arkadis, mlxsw, roopa, stephen, ivecera, nikolay
In-Reply-To: <20170608064428.4785-1-jiri@resnulli.us>
From: Arkadi Sharshevsky <arkadis@mellanox.com>
In order to use the switchdev notifier chain for FDB sync with the
device it has to be changed to atomic. The is done because the bridge
can learn new FDBs in atomic context.
Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/switchdev/switchdev.c | 30 ++++++------------------------
1 file changed, 6 insertions(+), 24 deletions(-)
diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
index 8d40a7d..25dc67e 100644
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@ -571,24 +571,17 @@ int switchdev_port_obj_dump(struct net_device *dev, struct switchdev_obj *obj,
}
EXPORT_SYMBOL_GPL(switchdev_port_obj_dump);
-static RAW_NOTIFIER_HEAD(switchdev_notif_chain);
+static ATOMIC_NOTIFIER_HEAD(switchdev_notif_chain);
/**
* register_switchdev_notifier - Register notifier
* @nb: notifier_block
*
- * Register switch device notifier. This should be used by code
- * which needs to monitor events happening in particular device.
- * Return values are same as for atomic_notifier_chain_register().
+ * Register switch device notifier.
*/
int register_switchdev_notifier(struct notifier_block *nb)
{
- int err;
-
- rtnl_lock();
- err = raw_notifier_chain_register(&switchdev_notif_chain, nb);
- rtnl_unlock();
- return err;
+ return atomic_notifier_chain_register(&switchdev_notif_chain, nb);
}
EXPORT_SYMBOL_GPL(register_switchdev_notifier);
@@ -597,16 +590,10 @@ EXPORT_SYMBOL_GPL(register_switchdev_notifier);
* @nb: notifier_block
*
* Unregister switch device notifier.
- * Return values are same as for atomic_notifier_chain_unregister().
*/
int unregister_switchdev_notifier(struct notifier_block *nb)
{
- int err;
-
- rtnl_lock();
- err = raw_notifier_chain_unregister(&switchdev_notif_chain, nb);
- rtnl_unlock();
- return err;
+ return atomic_notifier_chain_unregister(&switchdev_notif_chain, nb);
}
EXPORT_SYMBOL_GPL(unregister_switchdev_notifier);
@@ -616,18 +603,13 @@ EXPORT_SYMBOL_GPL(unregister_switchdev_notifier);
* @dev: port device
* @info: notifier information data
*
- * Call all network notifier blocks. This should be called by driver
- * when it needs to propagate hardware event.
- * Return values are same as for atomic_notifier_call_chain().
- * rtnl_lock must be held.
+ * Call all network notifier blocks.
*/
int call_switchdev_notifiers(unsigned long val, struct net_device *dev,
struct switchdev_notifier_info *info)
{
- ASSERT_RTNL();
-
info->dev = dev;
- return raw_notifier_call_chain(&switchdev_notif_chain, val, info);
+ return atomic_notifier_call_chain(&switchdev_notif_chain, val, info);
}
EXPORT_SYMBOL_GPL(call_switchdev_notifiers);
--
2.9.3
^ permalink raw reply related
* [patch net-next v2 03/19] net: bridge: Add support for calling FDB external learning under rcu
From: Jiri Pirko @ 2017-06-08 6:44 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, arkadis, mlxsw, roopa, stephen, ivecera, nikolay
In-Reply-To: <20170608064428.4785-1-jiri@resnulli.us>
From: Arkadi Sharshevsky <arkadis@mellanox.com>
This is done as a preparation to moving the switchdev notifier chain
to be atomic. The FDB external learning should be called under rtnl
or rcu.
Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/bridge/br.c | 4 ++--
net/bridge/br_fdb.c | 2 --
net/bridge/br_private.h | 6 ++++++
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/bridge/br.c b/net/bridge/br.c
index 889e564..e962fff 100644
--- a/net/bridge/br.c
+++ b/net/bridge/br.c
@@ -121,7 +121,7 @@ static struct notifier_block br_device_notifier = {
.notifier_call = br_device_event
};
-/* called with RTNL */
+/* called with RTNL or RCU */
static int br_switchdev_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
@@ -131,7 +131,7 @@ static int br_switchdev_event(struct notifier_block *unused,
struct switchdev_notifier_fdb_info *fdb_info;
int err = NOTIFY_DONE;
- p = br_port_get_rtnl(dev);
+ p = br_port_get_rtnl_rcu(dev);
if (!p)
goto out;
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index ab0c7cc..5c780cd 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -1075,7 +1075,6 @@ int br_fdb_external_learn_add(struct net_bridge *br, struct net_bridge_port *p,
struct net_bridge_fdb_entry *fdb;
int err = 0;
- ASSERT_RTNL();
spin_lock_bh(&br->hash_lock);
head = &br->hash[br_mac_hash(addr, vid)];
@@ -1110,7 +1109,6 @@ int br_fdb_external_learn_del(struct net_bridge *br, struct net_bridge_port *p,
struct net_bridge_fdb_entry *fdb;
int err = 0;
- ASSERT_RTNL();
spin_lock_bh(&br->hash_lock);
fdb = br_fdb_find(br, addr, vid);
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 7f43992..a122684 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -284,6 +284,12 @@ static inline struct net_bridge_port *br_port_get_rtnl(const struct net_device *
rtnl_dereference(dev->rx_handler_data) : NULL;
}
+static inline struct net_bridge_port *br_port_get_rtnl_rcu(const struct net_device *dev)
+{
+ return br_port_exists(dev) ?
+ rcu_dereference_rtnl(dev->rx_handler_data) : NULL;
+}
+
struct net_bridge {
spinlock_t lock;
spinlock_t hash_lock;
--
2.9.3
^ permalink raw reply related
* [patch net-next v2 02/19] net: bridge: Add support for offloading port attributes
From: Jiri Pirko @ 2017-06-08 6:44 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, arkadis, mlxsw, roopa, stephen, ivecera, nikolay
In-Reply-To: <20170608064428.4785-1-jiri@resnulli.us>
From: Arkadi Sharshevsky <arkadis@mellanox.com>
Currently the flood, learning and learning_sync port attributes are
offloaded by setting the SELF flag. Add support for offloading the
flood and learning attribute through the bridge code. In case of
setting an unsupported flag on a offloded port the operation will
fail.
The learning_sync attribute doesn't have any software representation
and cannot be offloaded through the bridge code.
Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/bridge/br_netlink.c | 87 +++++++++++++++++++++++++++++++++++------------
net/bridge/br_private.h | 10 ++++++
net/bridge/br_switchdev.c | 43 +++++++++++++++++++++++
3 files changed, 119 insertions(+), 21 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 3bcda55..63dca34 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -662,16 +662,26 @@ static int br_set_port_state(struct net_bridge_port *p, u8 state)
}
/* Set/clear or port flags based on attribute */
-static void br_set_port_flag(struct net_bridge_port *p, struct nlattr *tb[],
- int attrtype, unsigned long mask)
+static int br_set_port_flag(struct net_bridge_port *p, struct nlattr *tb[],
+ int attrtype, unsigned long mask)
{
- if (tb[attrtype]) {
- u8 flag = nla_get_u8(tb[attrtype]);
- if (flag)
- p->flags |= mask;
- else
- p->flags &= ~mask;
- }
+ unsigned long flags;
+ int err;
+
+ if (!tb[attrtype])
+ return 0;
+
+ if (nla_get_u8(tb[attrtype]))
+ flags = p->flags | mask;
+ else
+ flags = p->flags & ~mask;
+
+ err = br_switchdev_set_port_flag(p, flags, mask);
+ if (err)
+ return err;
+
+ p->flags = flags;
+ return 0;
}
/* Process bridge protocol info on port */
@@ -681,20 +691,55 @@ static int br_setport(struct net_bridge_port *p, struct nlattr *tb[])
bool br_vlan_tunnel_old = false;
int err;
- br_set_port_flag(p, tb, IFLA_BRPORT_MODE, BR_HAIRPIN_MODE);
- br_set_port_flag(p, tb, IFLA_BRPORT_GUARD, BR_BPDU_GUARD);
- br_set_port_flag(p, tb, IFLA_BRPORT_FAST_LEAVE, BR_MULTICAST_FAST_LEAVE);
- br_set_port_flag(p, tb, IFLA_BRPORT_PROTECT, BR_ROOT_BLOCK);
- br_set_port_flag(p, tb, IFLA_BRPORT_LEARNING, BR_LEARNING);
- br_set_port_flag(p, tb, IFLA_BRPORT_UNICAST_FLOOD, BR_FLOOD);
- br_set_port_flag(p, tb, IFLA_BRPORT_MCAST_FLOOD, BR_MCAST_FLOOD);
- br_set_port_flag(p, tb, IFLA_BRPORT_MCAST_TO_UCAST, BR_MULTICAST_TO_UNICAST);
- br_set_port_flag(p, tb, IFLA_BRPORT_BCAST_FLOOD, BR_BCAST_FLOOD);
- br_set_port_flag(p, tb, IFLA_BRPORT_PROXYARP, BR_PROXYARP);
- br_set_port_flag(p, tb, IFLA_BRPORT_PROXYARP_WIFI, BR_PROXYARP_WIFI);
+ err = br_set_port_flag(p, tb, IFLA_BRPORT_MODE, BR_HAIRPIN_MODE);
+ if (err)
+ return err;
+
+ err = br_set_port_flag(p, tb, IFLA_BRPORT_GUARD, BR_BPDU_GUARD);
+ if (err)
+ return err;
+
+ err = br_set_port_flag(p, tb, IFLA_BRPORT_FAST_LEAVE, BR_MULTICAST_FAST_LEAVE);
+ if (err)
+ return err;
+
+ err = br_set_port_flag(p, tb, IFLA_BRPORT_PROTECT, BR_ROOT_BLOCK);
+ if (err)
+ return err;
+
+ err = br_set_port_flag(p, tb, IFLA_BRPORT_LEARNING, BR_LEARNING);
+ if (err)
+ return err;
+
+ err = br_set_port_flag(p, tb, IFLA_BRPORT_UNICAST_FLOOD, BR_FLOOD);
+ if (err)
+ return err;
+
+ err = br_set_port_flag(p, tb, IFLA_BRPORT_MCAST_FLOOD, BR_MCAST_FLOOD);
+ if (err)
+ return err;
+
+ err = br_set_port_flag(p, tb, IFLA_BRPORT_MCAST_TO_UCAST, BR_MULTICAST_TO_UNICAST);
+ if (err)
+ return err;
+
+ err = br_set_port_flag(p, tb, IFLA_BRPORT_BCAST_FLOOD, BR_BCAST_FLOOD);
+ if (err)
+ return err;
+
+ err = br_set_port_flag(p, tb, IFLA_BRPORT_PROXYARP, BR_PROXYARP);
+ if (err)
+ return err;
+
+ err = br_set_port_flag(p, tb, IFLA_BRPORT_PROXYARP_WIFI, BR_PROXYARP_WIFI);
+ if (err)
+ return err;
br_vlan_tunnel_old = (p->flags & BR_VLAN_TUNNEL) ? true : false;
- br_set_port_flag(p, tb, IFLA_BRPORT_VLAN_TUNNEL, BR_VLAN_TUNNEL);
+ err = br_set_port_flag(p, tb, IFLA_BRPORT_VLAN_TUNNEL, BR_VLAN_TUNNEL);
+ if (err)
+ return err;
+
if (br_vlan_tunnel_old && !(p->flags & BR_VLAN_TUNNEL))
nbp_vlan_tunnel_info_flush(p);
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 2062692..7f43992 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -1076,6 +1076,9 @@ void nbp_switchdev_frame_mark(const struct net_bridge_port *p,
struct sk_buff *skb);
bool nbp_switchdev_allowed_egress(const struct net_bridge_port *p,
const struct sk_buff *skb);
+int br_switchdev_set_port_flag(struct net_bridge_port *p,
+ unsigned long flags,
+ unsigned long mask);
#else
static inline int nbp_switchdev_mark_set(struct net_bridge_port *p)
{
@@ -1092,6 +1095,13 @@ static inline bool nbp_switchdev_allowed_egress(const struct net_bridge_port *p,
{
return true;
}
+
+static inline int br_switchdev_set_port_flag(struct net_bridge_port *p,
+ unsigned long flags,
+ unsigned long mask)
+{
+ return 0;
+}
#endif /* CONFIG_NET_SWITCHDEV */
#endif
diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c
index f4097b9..b975959 100644
--- a/net/bridge/br_switchdev.c
+++ b/net/bridge/br_switchdev.c
@@ -55,3 +55,46 @@ bool nbp_switchdev_allowed_egress(const struct net_bridge_port *p,
return !skb->offload_fwd_mark ||
BR_INPUT_SKB_CB(skb)->offload_fwd_mark != p->offload_fwd_mark;
}
+
+/* Flags that can be offloaded to hardware */
+#define BR_PORT_FLAGS_HW_OFFLOAD (BR_LEARNING | BR_FLOOD | \
+ BR_MCAST_FLOOD | BR_BCAST_FLOOD)
+
+int br_switchdev_set_port_flag(struct net_bridge_port *p,
+ unsigned long flags,
+ unsigned long mask)
+{
+ struct switchdev_attr attr = {
+ .orig_dev = p->dev,
+ .id = SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
+ };
+ int err;
+
+ if (mask & ~BR_PORT_FLAGS_HW_OFFLOAD)
+ return 0;
+
+ err = switchdev_port_attr_get(p->dev, &attr);
+ if (err == -EOPNOTSUPP)
+ return 0;
+ if (err)
+ return err;
+
+ /* Check if specific bridge flag attribute offload is supported */
+ if (!(attr.u.brport_flags_support & mask)) {
+ br_warn(p->br, "bridge flag offload is not supported %u(%s)\n",
+ (unsigned int)p->port_no, p->dev->name);
+ return -EOPNOTSUPP;
+ }
+
+ attr.id = SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS;
+ attr.flags = SWITCHDEV_F_DEFER;
+ attr.u.brport_flags = flags;
+ err = switchdev_port_attr_set(p->dev, &attr);
+ if (err) {
+ br_warn(p->br, "error setting offload flag on port %u(%s)\n",
+ (unsigned int)p->port_no, p->dev->name);
+ return err;
+ }
+
+ return 0;
+}
--
2.9.3
^ permalink raw reply related
* [patch net-next v2 01/19] net: switchdev: Add support for querying supported bridge flags by hardware
From: Jiri Pirko @ 2017-06-08 6:44 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, arkadis, mlxsw, roopa, stephen, ivecera, nikolay
In-Reply-To: <20170608064428.4785-1-jiri@resnulli.us>
From: Arkadi Sharshevsky <arkadis@mellanox.com>
This is done as a preparation stage before setting the bridge port flags
from the bridge code. Currently the device can be queried for the bridge
flags state, but the querier cannot distinguish if the flag is disabled
or if it is not supported at all. Thus, add new attr and a bit-mask which
include information regarding the support on a per-flag basis.
Drivers that support bridge offload but not support bridge flags should
return zeroed bitmask.
Signed-off-by: Arkadi Sharshevsky <arkadis@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Ivan Vecera <ivecera@redhat.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
include/net/switchdev.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index 929d6af..63a754d 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -46,6 +46,7 @@ enum switchdev_attr_id {
SWITCHDEV_ATTR_ID_PORT_PARENT_ID,
SWITCHDEV_ATTR_ID_PORT_STP_STATE,
SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS,
+ SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
SWITCHDEV_ATTR_ID_PORT_MROUTER,
SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME,
SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING,
@@ -62,6 +63,7 @@ struct switchdev_attr {
struct netdev_phys_item_id ppid; /* PORT_PARENT_ID */
u8 stp_state; /* PORT_STP_STATE */
unsigned long brport_flags; /* PORT_BRIDGE_FLAGS */
+ unsigned long brport_flags_support; /* PORT_BRIDGE_FLAGS_SUPPORT */
bool mrouter; /* PORT_MROUTER */
clock_t ageing_time; /* BRIDGE_AGEING_TIME */
bool vlan_filtering; /* BRIDGE_VLAN_FILTERING */
--
2.9.3
^ permalink raw reply related
* [patch net-next v2 00/19] Remove support from bridge bypass for mlxsw/rocker drivers
From: Jiri Pirko @ 2017-06-08 6:44 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, arkadis, mlxsw, roopa, stephen, ivecera, nikolay
From: Jiri Pirko <jiri@mellanox.com>
Currently setting bridge port attributes and adding FDBs are done via
setting the SELF flag which implies unconsistent offloading model. This
patch-set fixes this behavior by making the bridge and drivers which are
using it to be totally in sync.
This implies several changes:
- Offloading bridge flags from the bridge code.
- Sending notification about FDB add/del to the software bridge in a
similiar way it is done for the hardware externally learned FDBs.
By making the offloading model more consistent a cleanup is done in
the drivers supporting it. This is done in order to remove un-needed
logic related to dump operation which is redundant.
First add missing functionality to bridge, then clean up the mlxsw/rocker
drivers.
---
v1->v2
- Move bridge-switchdev related stuff to br_switchdev.c as suggested by Nik
Arkadi Sharshevsky (19):
net: switchdev: Add support for querying supported bridge flags by
hardware
net: bridge: Add support for offloading port attributes
net: bridge: Add support for calling FDB external learning under rcu
net: switchdev: Change notifier chain to be atomic
net: bridge: Add support for notifying devices about FDB add/del
net: bridge: Receive notification about successful FDB offload
mlxsw: spectrum: Remove support for bridge FDB learning sync
mlxsw: spectrum_switchdev: Add support for querying supported bridge
flags
mlxsw: spectrum: Remove support for bypass bridge port attributes/vlan
set
mlxsw: spectrum_switchdev: Change switchdev notifier API
mlxsw: spectrum_switchdev: Add support for learning FDB through
notification
mlxsw: spectrum: Remove support for bridge bypass FDB add/del
net: Remove support for bridge bypass ndos from stacked devices
rocker: Remove support for bridge FDB learning sync
rocker: Add support for querying supported bridge flags
rocker: Change world_ops API and implementation to be switchdev
independant
rocker: Add support for learning FDB through notification
rocker: Remove support for bypass bridge port attributes/vlan set
rocker: Remove support bridge bypass FDB
drivers/net/bonding/bond_main.c | 6 -
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 8 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 +
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 360 +++++-------
drivers/net/ethernet/rocker/rocker.h | 21 +-
drivers/net/ethernet/rocker/rocker_main.c | 235 +++++---
drivers/net/ethernet/rocker/rocker_ofdpa.c | 610 ++++++++-------------
drivers/net/team/team.c | 6 -
include/net/switchdev.h | 9 +-
include/uapi/linux/neighbour.h | 1 +
net/8021q/vlan_dev.c | 6 -
net/bridge/br.c | 19 +-
net/bridge/br_fdb.c | 26 +-
net/bridge/br_netlink.c | 87 ++-
net/bridge/br_private.h | 28 +-
net/bridge/br_switchdev.c | 76 +++
net/switchdev/switchdev.c | 30 +-
17 files changed, 736 insertions(+), 793 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [PATCH net-next 00/16] nfp: ctrl vNIC
From: Jiri Pirko @ 2017-06-08 6:38 UTC (permalink / raw)
To: Mintz, Yuval
Cc: Jakub Kicinski, netdev@vger.kernel.org, oss-drivers@netronome.com
In-Reply-To: <BLUPR0701MB200495371E8CD9FDC59748B78DC90@BLUPR0701MB2004.namprd07.prod.outlook.com>
Thu, Jun 08, 2017 at 08:33:11AM CEST, Yuval.Mintz@cavium.com wrote:
>> >> >> >> >What were your plans with pre-netdev config?
>> >> >> >>
>> >> >> >> We need to pass come initial resource division. Generally the
>> >> >> >> consensus is to have these options exposed through devlink, let
>> >> >> >> the user configure them all and then to have a trigger that
>> >> >> >> would cause driver re-orchestration according to the new
>> >> >> >> values. The flow would look like
>> >> >> >> this:
>> >> >> >>
>> >> >> >> -driver loads with defaults, inits hw and instantiates netdevs
>> >> >> >> -driver exposes config options via devlink -user sets up the
>> >> >> >> options -user pushes the "go" trigger -upon the trigger
>> >> >> >> command, devlink calls the driver re-init callback -driver
>> >> >> >> shuts down the current instances, re-initializes hw,
>> >> >> >> re-instantiates the netdevs
>> >> >> >>
>> >> >> >> Makes sense?
>> >> >> >
>> >> >> >I like the idea of a "go"/apply/reload trigger and extending devlink.
>> >> >> >Do you plan on adding a way to persist the settings? I'm
>> >> >> >concerned NIC users may want to boot into the right mode once
>> >> >> >it's set, without reloads and reconfigs upon boot. Also is there
>> >> >> >going to be a way to query the pending/running config? Sounds
>> >> >> >like we may want to expose three value sets - persistent/default,
>> >> >> >running and pending/to be applied.
>> >> >
>> >> >> I don't think it is a good idea to introduce any kind of
>> >> >> configuration persistency in HW. I believe that user is the master
>> >> >> and he has all needed info. He can store it persistently, but it
>> >> >> is up to
>> >> him.
>> >> >>
>> >> >> So basicaly during boot, we need the devlink configuration to
>> >> >> happen early on, before the netdevices get configured. udev? Not
>> >> >> sure how exactly to do this. Have to ask around :)
>> >> >
>> >> >Thinking about use cases where we'd want information available at
>> >> >probe time, it might have been even better to have it separated from
>> >> >the netdevice, e.g., providing clients with node to configure
>> >> >(generic?) information on top of their PCI nodes.
>> >>
>> >> Yuval, devlink is separated from the netdevices....
>> >
>> >Separate from the netdevices, yes. But I think it's still a networking facility.
>> >I.e., would it make sense creating devlink nodes for PCI devices?
>>
>> True that devlink is placed in net/core. But from the very beginning, it was
>> designed to be multipurpose. So not only for net devices, but for any device
>> where is is suitable.
>>
>> >
>> >Anyway, I don't think there's any *strong* need for what I was asking
>> >for; It's simply that I was thinking of qed where there's quite a bit
>> >going on during the pci probe, and thought how re-doing it can be avoided.
>>
>> You can (should) register devlink early on way before netdevs.
>
>Given that I can't really register it sooner than the PCI probe,
>how would shortly-before or way-before differ?
Yeah. Pci probe is the limit :)
>
>Assume you have some userspace daemon monitoring devlink and applying
>user-provided configuration.
>How could it reliably apply the configuration between devlink registration
>and netdevice registeration?
You cannot assume that. That is why I suggested devlink config and then
a trigger to re-initialize the hw and the netdevices.
>
>The merit of the udev suggestion was that the sync. point was in userspace,
>so user could always make sure that devlink rules apply before netdev state changes.
>
>
^ permalink raw reply
* RE: [PATCH net-next 00/16] nfp: ctrl vNIC
From: Mintz, Yuval @ 2017-06-08 6:33 UTC (permalink / raw)
To: Jiri Pirko
Cc: Jakub Kicinski, netdev@vger.kernel.org, oss-drivers@netronome.com
In-Reply-To: <20170608053853.GA2238@nanopsycho>
> >> >> >> >What were your plans with pre-netdev config?
> >> >> >>
> >> >> >> We need to pass come initial resource division. Generally the
> >> >> >> consensus is to have these options exposed through devlink, let
> >> >> >> the user configure them all and then to have a trigger that
> >> >> >> would cause driver re-orchestration according to the new
> >> >> >> values. The flow would look like
> >> >> >> this:
> >> >> >>
> >> >> >> -driver loads with defaults, inits hw and instantiates netdevs
> >> >> >> -driver exposes config options via devlink -user sets up the
> >> >> >> options -user pushes the "go" trigger -upon the trigger
> >> >> >> command, devlink calls the driver re-init callback -driver
> >> >> >> shuts down the current instances, re-initializes hw,
> >> >> >> re-instantiates the netdevs
> >> >> >>
> >> >> >> Makes sense?
> >> >> >
> >> >> >I like the idea of a "go"/apply/reload trigger and extending devlink.
> >> >> >Do you plan on adding a way to persist the settings? I'm
> >> >> >concerned NIC users may want to boot into the right mode once
> >> >> >it's set, without reloads and reconfigs upon boot. Also is there
> >> >> >going to be a way to query the pending/running config? Sounds
> >> >> >like we may want to expose three value sets - persistent/default,
> >> >> >running and pending/to be applied.
> >> >
> >> >> I don't think it is a good idea to introduce any kind of
> >> >> configuration persistency in HW. I believe that user is the master
> >> >> and he has all needed info. He can store it persistently, but it
> >> >> is up to
> >> him.
> >> >>
> >> >> So basicaly during boot, we need the devlink configuration to
> >> >> happen early on, before the netdevices get configured. udev? Not
> >> >> sure how exactly to do this. Have to ask around :)
> >> >
> >> >Thinking about use cases where we'd want information available at
> >> >probe time, it might have been even better to have it separated from
> >> >the netdevice, e.g., providing clients with node to configure
> >> >(generic?) information on top of their PCI nodes.
> >>
> >> Yuval, devlink is separated from the netdevices....
> >
> >Separate from the netdevices, yes. But I think it's still a networking facility.
> >I.e., would it make sense creating devlink nodes for PCI devices?
>
> True that devlink is placed in net/core. But from the very beginning, it was
> designed to be multipurpose. So not only for net devices, but for any device
> where is is suitable.
>
> >
> >Anyway, I don't think there's any *strong* need for what I was asking
> >for; It's simply that I was thinking of qed where there's quite a bit
> >going on during the pci probe, and thought how re-doing it can be avoided.
>
> You can (should) register devlink early on way before netdevs.
Given that I can't really register it sooner than the PCI probe,
how would shortly-before or way-before differ?
Assume you have some userspace daemon monitoring devlink and applying
user-provided configuration.
How could it reliably apply the configuration between devlink registration
and netdevice registeration?
The merit of the udev suggestion was that the sync. point was in userspace,
so user could always make sure that devlink rules apply before netdev state changes.
^ permalink raw reply
* RE: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask
From: Grumbach, Emmanuel @ 2017-06-08 6:31 UTC (permalink / raw)
To: Seraphime Kirkovski, luca@coelho.fi
Cc: Berg, Johannes, Coelho, Luciano, linuxwifi, Kalle Valo,
open list:INTEL WIRELESS WIFI LINK (iwlwifi),
open list:NETWORKING DRIVERS, open list
In-Reply-To: <20170607223354.22399-1-kirkseraph@gmail.com>
Hi,
> Subject: [linuxwifi] [PATCH] net: wireless: intel: iwlwifi: dvm: fix tid mask
>
> Currently the tid mask covers the first 4 bits of iwlagn_tx_resp::ra_tid,
> which gives 16 possible values for tid.
> This is problematic because IWL_MAX_TID_COUNT is 8, so indexing
> iwl_priv::tid_data can go very wrong.
True, OTOH we need tid to be 8 sometimes. We *just* need to make sure
that we don't index tid_data with this. Hence I think the proper fix is:
diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
index 06ac3f1..16a8646 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/tx.c
@@ -1190,11 +1190,11 @@ void iwlagn_rx_reply_tx(struct iwl_priv *priv, struct iwl_rx_cmd_buffer *rxb)
next_reclaimed;
IWL_DEBUG_TX_REPLY(priv, "Next reclaimed packet:%d\n",
next_reclaimed);
+ iwlagn_check_ratid_empty(priv, sta_id, tid);
}
iwl_trans_reclaim(priv->trans, txq_id, ssn, &skbs);
- iwlagn_check_ratid_empty(priv, sta_id, tid);
freed = 0;
/* process frames */
Clearly calling iwlagn_check_ratid_empty with tid = IWL_TID_NON_QOS is a bad idea.
>
> With UBSAN I can it happening while establishing the first connection
> after module load.
>
> [ 272.143440] UBSAN: Undefined behaviour in
> drivers/net/wireless/intel/iwlwifi/dvm/tx.c:777:32
> [ 272.143447] index 8 is out of range for type 'iwl_tid_data [8]'
> [ 272.143457] CPU: 0 PID: 4605 Comm: irq/32-iwlwifi Not tainted 4.12.0-dirty
> #2
> [ 272.143460] Hardware name: Hewlett-Packard HP EliteBook 2560p/162B,
> BIOS 68SSU Ver. F.02 07/26/2011
> [ 272.143462] Call Trace:
> [ 272.143472] dump_stack+0x9c/0x10b
> [ 272.143477] ? _atomic_dec_and_lock+0x285/0x285
> [ 272.143486] ubsan_epilogue+0xd/0x4e
> [ 272.143493] __ubsan_handle_out_of_bounds+0xef/0x118
> [ 272.143498] ? __ubsan_handle_shift_out_of_bounds+0x221/0x221
> [ 272.143519] ? iwl_trans_pcie_reclaim+0x153/0xc90 [iwlwifi]
> [ 272.143539] iwlagn_check_ratid_empty+0x337/0x410 [iwldvm]
> [ 272.143556] ? iwl_hcmd_names_cmp+0x2f/0x60 [iwlwifi]
> [ 272.143571] iwlagn_rx_reply_tx+0x8a4/0x1820 [iwldvm]
>
> Signed-off-by: Seraphime Kirkovski <kirkseraph@gmail.com>
> ---
> I'm currently running this patch on my machines and I have wifi.
> The patch presumes а cleanup patch, I sent yesterday:
> https://www.spinics.net/lists/kernel/msg2526314.html
>
> drivers/net/wireless/intel/iwlwifi/dvm/commands.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> b/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> index 37d2ba5ae852..e5994df9ea4c 100644
> --- a/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> +++ b/drivers/net/wireless/intel/iwlwifi/dvm/commands.h
> @@ -1448,7 +1448,7 @@ struct agg_tx_status {
> */
> /* refer to ra_tid */
> #define IWLAGN_TX_RES_TID_POS 0
> -#define IWLAGN_TX_RES_TID_MSK 0x0f
> +#define IWLAGN_TX_RES_TID_MSK 0x07
> #define IWLAGN_TX_RES_RA_POS 4
> #define IWLAGN_TX_RES_RA_MSK 0xf0
>
> --
> 2.11.0
>
> -------------------------------------
> linuxwifi@eclists.intel.com
> https://eclists.intel.com/sympa/info/linuxwifi
> Unsubscribe by sending email to sympa@eclists.intel.com with subject
> "Unsubscribe linuxwifi"
^ permalink raw reply related
* [PATCH 2/2] drivers: net: emac: add const to mii_phy_ops structures
From: Bhumika Goyal @ 2017-06-08 6:00 UTC (permalink / raw)
To: julia.lawall, netdev, linux-kernel, jeffrey.t.kirsher, davem
Cc: Bhumika Goyal
In-Reply-To: <1496901658-6476-1-git-send-email-bhumirks@gmail.com>
The object references of mii_phy_ops structures are only stored
in the ops field of a mii_phy_def structure. This ops field is of type
const. So, mii_phy_ops structures having similar properties can be
declared as const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/ethernet/ibm/emac/phy.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/ibm/emac/phy.c b/drivers/net/ethernet/ibm/emac/phy.c
index 5b88cc6..35865d0 100644
--- a/drivers/net/ethernet/ibm/emac/phy.c
+++ b/drivers/net/ethernet/ibm/emac/phy.c
@@ -276,7 +276,7 @@ static int genmii_read_link(struct mii_phy *phy)
}
/* Generic implementation for most 10/100/1000 PHYs */
-static struct mii_phy_ops generic_phy_ops = {
+static const struct mii_phy_ops generic_phy_ops = {
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
.poll_link = genmii_poll_link,
@@ -340,7 +340,7 @@ static int cis8201_init(struct mii_phy *phy)
return 0;
}
-static struct mii_phy_ops cis8201_phy_ops = {
+static const struct mii_phy_ops cis8201_phy_ops = {
.init = cis8201_init,
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
@@ -420,7 +420,7 @@ static int et1011c_init(struct mii_phy *phy)
return 0;
}
-static struct mii_phy_ops et1011c_phy_ops = {
+static const struct mii_phy_ops et1011c_phy_ops = {
.init = et1011c_init,
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
@@ -439,7 +439,7 @@ static struct mii_phy_def et1011c_phy_def = {
-static struct mii_phy_ops m88e1111_phy_ops = {
+static const struct mii_phy_ops m88e1111_phy_ops = {
.init = m88e1111_init,
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
@@ -455,7 +455,7 @@ static struct mii_phy_def m88e1111_phy_def = {
.ops = &m88e1111_phy_ops,
};
-static struct mii_phy_ops m88e1112_phy_ops = {
+static const struct mii_phy_ops m88e1112_phy_ops = {
.init = m88e1112_init,
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
@@ -480,7 +480,7 @@ static int ar8035_init(struct mii_phy *phy)
return 0;
}
-static struct mii_phy_ops ar8035_phy_ops = {
+static const struct mii_phy_ops ar8035_phy_ops = {
.init = ar8035_init,
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] drivers/net/sungem: add const to mii_phy_ops structures
From: Bhumika Goyal @ 2017-06-08 6:00 UTC (permalink / raw)
To: julia.lawall, netdev, linux-kernel, jeffrey.t.kirsher, davem
Cc: Bhumika Goyal
In-Reply-To: <1496901658-6476-1-git-send-email-bhumirks@gmail.com>
The object references of mii_phy_ops structures are only stored
in the ops field of a mii_phy_def structure. This ops field is of type
const. So, mii_phy_ops structures having similar properties can be
declared as const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
drivers/net/sungem_phy.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/net/sungem_phy.c b/drivers/net/sungem_phy.c
index 92578d72..63a8ff8 100644
--- a/drivers/net/sungem_phy.c
+++ b/drivers/net/sungem_phy.c
@@ -886,7 +886,7 @@ static int marvell_read_link(struct mii_phy *phy)
SUPPORTED_1000baseT_Half | SUPPORTED_1000baseT_Full)
/* Broadcom BCM 5201 */
-static struct mii_phy_ops bcm5201_phy_ops = {
+static const struct mii_phy_ops bcm5201_phy_ops = {
.init = bcm5201_init,
.suspend = bcm5201_suspend,
.setup_aneg = genmii_setup_aneg,
@@ -905,7 +905,7 @@ static struct mii_phy_def bcm5201_phy_def = {
};
/* Broadcom BCM 5221 */
-static struct mii_phy_ops bcm5221_phy_ops = {
+static const struct mii_phy_ops bcm5221_phy_ops = {
.suspend = bcm5221_suspend,
.init = bcm5221_init,
.setup_aneg = genmii_setup_aneg,
@@ -924,7 +924,7 @@ static struct mii_phy_def bcm5221_phy_def = {
};
/* Broadcom BCM 5241 */
-static struct mii_phy_ops bcm5241_phy_ops = {
+static const struct mii_phy_ops bcm5241_phy_ops = {
.suspend = bcm5241_suspend,
.init = bcm5241_init,
.setup_aneg = genmii_setup_aneg,
@@ -942,7 +942,7 @@ static struct mii_phy_def bcm5241_phy_def = {
};
/* Broadcom BCM 5400 */
-static struct mii_phy_ops bcm5400_phy_ops = {
+static const struct mii_phy_ops bcm5400_phy_ops = {
.init = bcm5400_init,
.suspend = bcm5400_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -961,7 +961,7 @@ static struct mii_phy_def bcm5400_phy_def = {
};
/* Broadcom BCM 5401 */
-static struct mii_phy_ops bcm5401_phy_ops = {
+static const struct mii_phy_ops bcm5401_phy_ops = {
.init = bcm5401_init,
.suspend = bcm5401_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -980,7 +980,7 @@ static struct mii_phy_def bcm5401_phy_def = {
};
/* Broadcom BCM 5411 */
-static struct mii_phy_ops bcm5411_phy_ops = {
+static const struct mii_phy_ops bcm5411_phy_ops = {
.init = bcm5411_init,
.suspend = generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -999,7 +999,7 @@ static struct mii_phy_def bcm5411_phy_def = {
};
/* Broadcom BCM 5421 */
-static struct mii_phy_ops bcm5421_phy_ops = {
+static const struct mii_phy_ops bcm5421_phy_ops = {
.init = bcm5421_init,
.suspend = generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -1019,7 +1019,7 @@ static struct mii_phy_def bcm5421_phy_def = {
};
/* Broadcom BCM 5421 built-in K2 */
-static struct mii_phy_ops bcm5421k2_phy_ops = {
+static const struct mii_phy_ops bcm5421k2_phy_ops = {
.init = bcm5421_init,
.suspend = generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -1037,7 +1037,7 @@ static struct mii_phy_def bcm5421k2_phy_def = {
.ops = &bcm5421k2_phy_ops
};
-static struct mii_phy_ops bcm5461_phy_ops = {
+static const struct mii_phy_ops bcm5461_phy_ops = {
.init = bcm5421_init,
.suspend = generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -1057,7 +1057,7 @@ static struct mii_phy_def bcm5461_phy_def = {
};
/* Broadcom BCM 5462 built-in Vesta */
-static struct mii_phy_ops bcm5462V_phy_ops = {
+static const struct mii_phy_ops bcm5462V_phy_ops = {
.init = bcm5421_init,
.suspend = generic_suspend,
.setup_aneg = bcm54xx_setup_aneg,
@@ -1076,7 +1076,7 @@ static struct mii_phy_def bcm5462V_phy_def = {
};
/* Marvell 88E1101 amd 88E1111 */
-static struct mii_phy_ops marvell88e1101_phy_ops = {
+static const struct mii_phy_ops marvell88e1101_phy_ops = {
.suspend = generic_suspend,
.setup_aneg = marvell_setup_aneg,
.setup_forced = marvell_setup_forced,
@@ -1084,7 +1084,7 @@ static struct mii_phy_ops marvell88e1101_phy_ops = {
.read_link = marvell_read_link
};
-static struct mii_phy_ops marvell88e1111_phy_ops = {
+static const struct mii_phy_ops marvell88e1111_phy_ops = {
.init = marvell88e1111_init,
.suspend = generic_suspend,
.setup_aneg = marvell_setup_aneg,
@@ -1122,7 +1122,7 @@ static struct mii_phy_def marvell88e1111_phy_def = {
};
/* Generic implementation for most 10/100 PHYs */
-static struct mii_phy_ops generic_phy_ops = {
+static const struct mii_phy_ops generic_phy_ops = {
.setup_aneg = genmii_setup_aneg,
.setup_forced = genmii_setup_forced,
.poll_link = genmii_poll_link,
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] drivers: net: add const to mii_phy_ops structures
From: Bhumika Goyal @ 2017-06-08 6:00 UTC (permalink / raw)
To: julia.lawall, netdev, linux-kernel, jeffrey.t.kirsher, davem
Cc: Bhumika Goyal
The object references of mii_phy_ops structures are only stored
in the ops field of a mii_phy_def structure. This ops field is of type
const. So, mii_phy_ops structures having similar properties can be
declared as const.
Bhumika Goyal (2):
drivers/net/sungem: add const to mii_phy_ops structures
drivers: net: emac: add const to mii_phy_ops structures
drivers/net/ethernet/ibm/emac/phy.c | 12 ++++++------
drivers/net/sungem_phy.c | 26 +++++++++++++-------------
2 files changed, 19 insertions(+), 19 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH net-next 00/16] nfp: ctrl vNIC
From: Jiri Pirko @ 2017-06-08 5:38 UTC (permalink / raw)
To: Mintz, Yuval
Cc: Jakub Kicinski, netdev@vger.kernel.org, oss-drivers@netronome.com
In-Reply-To: <BLUPR0701MB200425BE49D0578371379A138DC80@BLUPR0701MB2004.namprd07.prod.outlook.com>
Wed, Jun 07, 2017 at 07:48:08PM CEST, Yuval.Mintz@cavium.com wrote:
>> >> >> >What were your plans with pre-netdev config?
>> >> >>
>> >> >> We need to pass come initial resource division. Generally the
>> >> >> consensus is to have these options exposed through devlink, let
>> >> >> the user configure them all and then to have a trigger that would
>> >> >> cause driver re-orchestration according to the new values. The
>> >> >> flow would look like
>> >> >> this:
>> >> >>
>> >> >> -driver loads with defaults, inits hw and instantiates netdevs
>> >> >> -driver exposes config options via devlink -user sets up the
>> >> >> options -user pushes the "go" trigger -upon the trigger command,
>> >> >> devlink calls the driver re-init callback -driver shuts down the
>> >> >> current instances, re-initializes hw, re-instantiates the netdevs
>> >> >>
>> >> >> Makes sense?
>> >> >
>> >> >I like the idea of a "go"/apply/reload trigger and extending devlink.
>> >> >Do you plan on adding a way to persist the settings? I'm concerned
>> >> >NIC users may want to boot into the right mode once it's set,
>> >> >without reloads and reconfigs upon boot. Also is there going to be
>> >> >a way to query the pending/running config? Sounds like we may want
>> >> >to expose three value sets - persistent/default, running and
>> >> >pending/to be applied.
>> >
>> >> I don't think it is a good idea to introduce any kind of
>> >> configuration persistency in HW. I believe that user is the master
>> >> and he has all needed info. He can store it persistently, but it is up to
>> him.
>> >>
>> >> So basicaly during boot, we need the devlink configuration to happen
>> >> early on, before the netdevices get configured. udev? Not sure how
>> >> exactly to do this. Have to ask around :)
>> >
>> >Thinking about use cases where we'd want information available at probe
>> >time, it might have been even better to have it separated from the
>> >netdevice, e.g., providing clients with node to configure (generic?)
>> >information on top of their PCI nodes.
>>
>> Yuval, devlink is separated from the netdevices....
>
>Separate from the netdevices, yes. But I think it's still a networking facility.
>I.e., would it make sense creating devlink nodes for PCI devices?
True that devlink is placed in net/core. But from the very beginning, it
was designed to be multipurpose. So not only for net devices, but for
any device where is is suitable.
>
>Anyway, I don't think there's any *strong* need for what I was asking for;
>It's simply that I was thinking of qed where there's quite a bit going on
>during the pci probe, and thought how re-doing it can be avoided.
You can (should) register devlink early on way before netdevs.
^ permalink raw reply
* [net-next 1/2] igb: make a few local functions static
From: Jeff Kirsher @ 2017-06-08 5:32 UTC (permalink / raw)
To: davem; +Cc: Colin Ian King, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170608053237.73040-1-jeffrey.t.kirsher@intel.com>
From: Colin Ian King <colin.king@canonical.com>
Clean up a few sparse warnings, these following
functions can be made static:
drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol
'igb_add_mac_filter' was not declared. Should it be static?
drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol
'igb_del_mac_filter' was not declared. Should it be static?
drivers/net/ethernet/intel/igb/igb_main.c: warning: symbol
'igb_set_vf_mac_filter' was not declared. Should it be static?
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 7e433344a13c..ec62410b035a 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -6469,8 +6469,8 @@ static void igb_set_default_mac_filter(struct igb_adapter *adapter)
igb_rar_set_index(adapter, 0);
}
-int igb_add_mac_filter(struct igb_adapter *adapter, const u8 *addr,
- const u8 queue)
+static int igb_add_mac_filter(struct igb_adapter *adapter, const u8 *addr,
+ const u8 queue)
{
struct e1000_hw *hw = &adapter->hw;
int rar_entries = hw->mac.rar_entry_count -
@@ -6499,8 +6499,8 @@ int igb_add_mac_filter(struct igb_adapter *adapter, const u8 *addr,
return -ENOSPC;
}
-int igb_del_mac_filter(struct igb_adapter *adapter, const u8 *addr,
- const u8 queue)
+static int igb_del_mac_filter(struct igb_adapter *adapter, const u8 *addr,
+ const u8 queue)
{
struct e1000_hw *hw = &adapter->hw;
int rar_entries = hw->mac.rar_entry_count -
@@ -6552,8 +6552,8 @@ static int igb_uc_unsync(struct net_device *netdev, const unsigned char *addr)
return 0;
}
-int igb_set_vf_mac_filter(struct igb_adapter *adapter, const int vf,
- const u32 info, const u8 *addr)
+static int igb_set_vf_mac_filter(struct igb_adapter *adapter, const int vf,
+ const u32 info, const u8 *addr)
{
struct pci_dev *pdev = adapter->pdev;
struct vf_data_storage *vf_data = &adapter->vf_data[vf];
--
2.12.2
^ permalink raw reply related
* [net-next 2/2] e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails
From: Jeff Kirsher @ 2017-06-08 5:32 UTC (permalink / raw)
To: davem
Cc: Chris Wilson, netdev, nhorman, sassmann, jogreene, Jani Nikula,
Jeff Kirsher
In-Reply-To: <20170608053237.73040-1-jeffrey.t.kirsher@intel.com>
From: Chris Wilson <chris@chris-wilson.co.uk>
An error during suspend (e100e_pm_suspend),
[ 429.994338] ACPI : EC: event blocked
[ 429.994633] e1000e: EEE TX LPI TIMER: 00000011
[ 430.955451] pci_pm_suspend(): e1000e_pm_suspend+0x0/0x30 [e1000e] returns -2
[ 430.955454] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -2
[ 430.955458] PM: Device 0000:00:19.0 failed to suspend async: error -2
[ 430.955581] PM: Some devices failed to suspend, or early wake event detected
[ 430.957709] ACPI : EC: event unblocked
lead to complete failure:
[ 432.585002] ------------[ cut here ]------------
[ 432.585013] WARNING: CPU: 3 PID: 8372 at kernel/irq/manage.c:1478 __free_irq+0x9f/0x280
[ 432.585015] Trying to free already-free IRQ 20
[ 432.585016] Modules linked in: cdc_ncm usbnet x86_pkg_temp_thermal intel_powerclamp coretemp mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm mei_me mei sdhci_pci sdhci i915 mmc_core e1000e ptp pps_core prime_numbers
[ 432.585042] CPU: 3 PID: 8372 Comm: kworker/u16:40 Tainted: G U 4.10.0-rc8-CI-Patchwork_3870+ #1
[ 432.585044] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 07/02/2012
[ 432.585050] Workqueue: events_unbound async_run_entry_fn
[ 432.585051] Call Trace:
[ 432.585058] dump_stack+0x67/0x92
[ 432.585062] __warn+0xc6/0xe0
[ 432.585065] warn_slowpath_fmt+0x4a/0x50
[ 432.585070] ? _raw_spin_lock_irqsave+0x49/0x60
[ 432.585072] __free_irq+0x9f/0x280
[ 432.585075] free_irq+0x34/0x80
[ 432.585089] e1000_free_irq+0x65/0x70 [e1000e]
[ 432.585098] e1000e_pm_freeze+0x7a/0xb0 [e1000e]
[ 432.585106] e1000e_pm_suspend+0x21/0x30 [e1000e]
[ 432.585113] pci_pm_suspend+0x71/0x140
[ 432.585118] dpm_run_callback+0x6f/0x330
[ 432.585122] ? pci_pm_freeze+0xe0/0xe0
[ 432.585125] __device_suspend+0xea/0x330
[ 432.585128] async_suspend+0x1a/0x90
[ 432.585132] async_run_entry_fn+0x34/0x160
[ 432.585137] process_one_work+0x1f4/0x6d0
[ 432.585140] ? process_one_work+0x16e/0x6d0
[ 432.585143] worker_thread+0x49/0x4a0
[ 432.585145] kthread+0x107/0x140
[ 432.585148] ? process_one_work+0x6d0/0x6d0
[ 432.585150] ? kthread_create_on_node+0x40/0x40
[ 432.585154] ret_from_fork+0x2e/0x40
[ 432.585156] ---[ end trace 6712df7f8c4b9124 ]---
The unwind failures stems from commit 2800209994f8 ("e1000e: Refactor PM
flows"), but it may be a later patch that introduced the non-recoverable
behaviour.
Fixes: 2800209994f8 ("e1000e: Refactor PM flows")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99847
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index e1d46c11cb61..2dcb5463d9b8 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6640,12 +6640,17 @@ static int e1000e_pm_thaw(struct device *dev)
static int e1000e_pm_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
+ int rc;
e1000e_flush_lpic(pdev);
e1000e_pm_freeze(dev);
- return __e1000_shutdown(pdev, false);
+ rc = __e1000_shutdown(pdev, false);
+ if (rc)
+ e1000e_pm_thaw(dev);
+
+ return rc;
}
static int e1000e_pm_resume(struct device *dev)
--
2.12.2
^ permalink raw reply related
* [net-next 0/2][pull request] 1GbE Intel Wired LAN Driver Updates 2017-06-07
From: Jeff Kirsher @ 2017-06-08 5:32 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains a fix for e1000e and igb.
Colin Ian King fixes sparse warnings in igb by making functions static.
Chris Wilson provides a fix for a previous commit which is causing an
issue during suspend "e1000e_pm_suspend()", where we need to run
e1000e_pm_thaw() if __e1000_shutdown() is unsuccessful.
The following are changes since commit 50dffe7fad6c156c2928e45c19ff7b86eb951f4c:
Merge branch 'mlx4-drivers-version-update'
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 1GbE
Chris Wilson (1):
e1000e: Undo e1000e_pm_freeze if __e1000_shutdown fails
Colin Ian King (1):
igb: make a few local functions static
drivers/net/ethernet/intel/e1000e/netdev.c | 7 ++++++-
drivers/net/ethernet/intel/igb/igb_main.c | 12 ++++++------
2 files changed, 12 insertions(+), 7 deletions(-)
--
2.12.2
^ permalink raw reply
* [PATCH net-next] cxgb4: fix to bring link down after adapter crash
From: Ganesh Goudar @ 2017-06-08 5:22 UTC (permalink / raw)
To: netdev, davem
Cc: nirranjan, indranil, venkatesh, Rahul Lakkireddy, Ganesh Goudar
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Use PORT_REG for T4 and T5_PORT_REG for > T4 to write to correct
register to bring down link during shutdown after adapter crash.
Signed-off-by: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 4618185..da1322d 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -7688,10 +7688,9 @@ int t4_shutdown_adapter(struct adapter *adapter)
t4_intr_disable(adapter);
t4_write_reg(adapter, DBG_GPIO_EN_A, 0);
for_each_port(adapter, port) {
- u32 a_port_cfg = PORT_REG(port,
- is_t4(adapter->params.chip)
- ? XGMAC_PORT_CFG_A
- : MAC_PORT_CFG_A);
+ u32 a_port_cfg = is_t4(adapter->params.chip) ?
+ PORT_REG(port, XGMAC_PORT_CFG_A) :
+ T5_PORT_REG(port, MAC_PORT_CFG_A);
t4_write_reg(adapter, a_port_cfg,
t4_read_reg(adapter, a_port_cfg)
--
2.1.0
^ permalink raw reply related
* Re: Netlink messages without NLM_F_REQUEST flag
From: Leon Romanovsky @ 2017-06-08 5:08 UTC (permalink / raw)
To: Jason Gunthorpe, Hefty, Sean
Cc: Kaike Wan, John Fleck, Ira Weiny, Thomas Graf, Doug Ledford,
Jiri Pirko, RDMA mailing list, linux-netdev
In-Reply-To: <20170607183511.GA10225-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
On Wed, Jun 07, 2017 at 12:35:11PM -0600, Jason Gunthorpe wrote:
> On Wed, Jun 07, 2017 at 09:18:10PM +0300, Leon Romanovsky wrote:
>
> > > AFAIK, that is different, that is acking and retriggering a single shot
> > > notification, not completing a kernel initiated handshake.
> >
> > It is acking that message from user was received by kernel and now
> > processing.
>
> But isn't what is cared about here - the SA thing needs to send a
> request to user space and collect a reply, it runs the protocol
> backwards from normal.
Thanks all, this explain a little bit "RDMA anomaly".
I'm not sure that I saw such scheme in the kernel, does anybody else
in the kernel use such backward scheme or this is RDMA-specific?
Thanks
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/2] ip6_tunnel: fix potential issue in __ip6_tnl_rcv
From: Alexei Starovoitov @ 2017-06-08 5:00 UTC (permalink / raw)
To: 严海双; +Cc: =David S. Miller, netdev, Eric Dumazet
In-Reply-To: <3A078CA0-C9C8-45D2-A359-1FB38B25792D@cmss.chinamobile.com>
On Thu, Jun 08, 2017 at 12:56:58PM +0800, 严海双 wrote:
>
> > On 8 Jun 2017, at 12:38 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >
> > On Thu, Jun 08, 2017 at 12:32:44PM +0800, Haishuang Yan wrote:
> >> When __ip6_tnl_rcv fails, the tun_dst won't be freed, so call
> >> dst_release to free it in error code path.
> >>
> >> CC: Alexei Starovoitov <ast@fb.com>
> >> Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
> >> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
> >
> > I don't get it. Why did you send another version of the patch?
> > What was wrong with previous approach that myself and Eric acked?
> >
> >
>
> Sorry for your confusing, because Pravin Shelar give a feedback in ipv4 patch, see below:
hmm. right.
Then it raises the question: How did you test this and previous patch?
since previous version was sort-of fixing the bug, but completely
breaking the logic...
^ permalink raw reply
* Investment Interest & Offer
From: Seydou Thieba @ 2017-06-02 23:01 UTC (permalink / raw)
To: Recipients
We are a Fund management company located in the United Kingdom, we specialize in searching for potential investments opportunities for our high net-worth clients globally. Should this be of interest to you, please do not hesitate to email me for further information.
Thanks
Seydou Thieba
---
This email has been checked for viruses by AVG.
http://www.avg.com
^ permalink raw reply
* Re: [PATCH v3 1/2] ip_tunnel: fix potential issue in ip_tunnel_rcv
From: Eric Dumazet @ 2017-06-08 4:54 UTC (permalink / raw)
To: Haishuang Yan; +Cc: netdev, linux-kernel, Pravin B Shelar
In-Reply-To: <1496896364-27153-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
On Thu, 2017-06-08 at 12:32 +0800, Haishuang Yan wrote:
> When ip_tunnel_rcv fails, the tun_dst won't be freed, so call
> dst_release to free it in error code path.
>
> CC: Pravin B Shelar <pshelar@nicira.com>
> Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.")
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>
> ---
> Changes in v2:
> - Add the the missing Fixes information
> Changes in v3:
> - Free tun_dst from error code path
> ---
> net/ipv4/ip_tunnel.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index b878ecb..0f1d876 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -446,6 +446,8 @@ int ip_tunnel_rcv(struct ip_tunnel *tunnel, struct sk_buff *skb,
> return 0;
>
> drop:
> + if (tun_dst)
> + dst_release((struct dst_entry *)tun_dst);
> kfree_skb(skb);
> return 0;
> }
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH v3 2/2] ip6_tunnel: fix potential issue in __ip6_tnl_rcv
From: Eric Dumazet @ 2017-06-08 4:50 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Haishuang Yan, =David S. Miller, netdev
In-Reply-To: <20170608043847.uejvydlitzuik76j@ast-mbp>
On Wed, Jun 7, 2017 at 9:38 PM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Thu, Jun 08, 2017 at 12:32:44PM +0800, Haishuang Yan wrote:
>> When __ip6_tnl_rcv fails, the tun_dst won't be freed, so call
>> dst_release to free it in error code path.
>>
>> CC: Alexei Starovoitov <ast@fb.com>
>> Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
>> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
>
> I don't get it. Why did you send another version of the patch?
> What was wrong with previous approach that myself and Eric acked?
>
Answer lies in Pravin feedback on v2 of the patch on ipv4 side.
^ permalink raw reply
* Re: [PATCH v3 2/2] ip6_tunnel: fix potential issue in __ip6_tnl_rcv
From: Alexei Starovoitov @ 2017-06-08 4:38 UTC (permalink / raw)
To: Haishuang Yan; +Cc: =David S. Miller, netdev, Eric Dumazet
In-Reply-To: <1496896364-27153-2-git-send-email-yanhaishuang@cmss.chinamobile.com>
On Thu, Jun 08, 2017 at 12:32:44PM +0800, Haishuang Yan wrote:
> When __ip6_tnl_rcv fails, the tun_dst won't be freed, so call
> dst_release to free it in error code path.
>
> CC: Alexei Starovoitov <ast@fb.com>
> Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
I don't get it. Why did you send another version of the patch?
What was wrong with previous approach that myself and Eric acked?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox