* Re: tc: Using u32 filter
From: Jiri Pirko @ 2018-04-27 15:04 UTC (permalink / raw)
To: Jose Abreu; +Cc: netdev@vger.kernel.org, Joao Pinto
In-Reply-To: <27482470-930e-916d-2ace-deedf3019369@synopsys.com>
Fri, Apr 27, 2018 at 04:15:46PM CEST, Jose.Abreu@synopsys.com wrote:
>Hi,
>
>I'm trying to use u32 filter to filter specific fields of packets
>by HW *only* but I'm having a hard time in trying to run tc to
>configure it.
>I implemented a dummy .ndo_setup_tc callback which always returns
>success and I set NETIF_F_HW_TC field in hw_features. Then I run
Did you register a block cb?
>tc, like this:
>
> # tc filter add dev eth0 u32 skip_sw sample u32 20 ffff at 0
>
>At this stage I'm not really caring about the packet content (the
>"20 ffff at 0"), I just want to see the configuration reaching my
>driver but I'm getting a "RTNETLINK answers: Operation not
>supported" error.
>
>Can you tell me what I'm I doing wrong?
>
>Thanks and Best Regards,
>Jose Miguel Abreu
^ permalink raw reply
* Re: [net-next 1/1] tipc: introduce ioctl for fetching node identity
From: David Miller @ 2018-04-27 15:05 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, mohan.krishna.ghanta.krishnamurthy, tung.q.nguyen,
hoang.h.le, canh.d.luu, ying.xue, tipc-discussion
In-Reply-To: <1524677376-29004-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Wed, 25 Apr 2018 19:29:36 +0200
> After the introduction of a 128-bit node identity it may be difficult
> for a user to correlate between this identity and the generated node
> hash address.
>
> We now try to make this easier by introducing a new ioctl() call for
> fetching a node identity by using the hash value as key. This will
> be particularly useful when we extend some of the commands in the
> 'tipc' tool, but we also expect regular user applications to need
> this feature.
>
> Acked-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
I hate ioctls, but I can't suggest anything better in this case.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] l2tp: consistent reference counting in procfs and debufs
From: David Miller @ 2018-04-27 15:06 UTC (permalink / raw)
To: g.nault; +Cc: netdev, jchapman
In-Reply-To: <05e09a546a94331e43d9e771f6ce515b1cdbf521.1524678712.git.g.nault@alphalink.fr>
From: Guillaume Nault <g.nault@alphalink.fr>
Date: Wed, 25 Apr 2018 19:54:14 +0200
> The 'pppol2tp' procfs and 'l2tp/tunnels' debugfs files handle reference
> counting of sessions differently than for tunnels.
>
> For consistency, use the same mechanism for handling both sessions and
> tunnels. That is, drop the reference on the previous session just
> before looking up the next one (rather than in .show()). If necessary
> (if dump stops before *_next_session() returns NULL), drop the last
> reference in .stop().
>
> Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Applied.
Your continued bug fixing and clenaups in this area are very much appreciated.
^ permalink raw reply
* Re: [PATCH net-next 6/6] liquidio: enhanced ethtool --set-channels feature
From: kbuild test robot @ 2018-04-27 15:07 UTC (permalink / raw)
To: Felix Manlunas
Cc: kbuild-all, davem, netdev, raghu.vatsavayi, derek.chickles,
satananda.burla, felix.manlunas, intiyaz.basha
In-Reply-To: <20180425182350.GA13911@felix-thinkpad.cavium.com>
Hi Intiyaz,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Felix-Manlunas/liquidio-enhanced-ethtool-set-channels-feature/20180427-195934
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:869:22: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [unsigned] [usertype] major @@ got short [unsigned] [usertype] major @@
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:869:22: expected unsigned short [unsigned] [usertype] major
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:869:22: got restricted __be16 [usertype] <noident>
>> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:870:22: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [unsigned] [usertype] minor @@ got short [unsigned] [usertype] minor @@
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:870:22: expected unsigned short [unsigned] [usertype] minor
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:870:22: got restricted __be16 [usertype] <noident>
>> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:871:22: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [unsigned] [usertype] micro @@ got short [unsigned] [usertype] micro @@
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:871:22: expected unsigned short [unsigned] [usertype] micro
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:871:22: got restricted __be16 [usertype] <noident>
>> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:840:5: sparse: symbol 'lio_23xx_reconfigure_queue_count' was not declared. Should it be static?
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1126:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:1128:20: sparse: expression using sizeof(void)
Please review and possibly fold the followup patch.
vim +869 drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
839
> 840 int lio_23xx_reconfigure_queue_count(struct lio *lio)
841 {
842 struct octeon_device *oct = lio->oct_dev;
843 struct liquidio_if_cfg_context *ctx;
844 u32 resp_size, ctx_size, data_size;
845 struct liquidio_if_cfg_resp *resp;
846 struct octeon_soft_command *sc;
847 union oct_nic_if_cfg if_cfg;
848 struct lio_version *vdata;
849 u32 ifidx_or_pfnum;
850 int retval;
851 int j;
852
853 resp_size = sizeof(struct liquidio_if_cfg_resp);
854 ctx_size = sizeof(struct liquidio_if_cfg_context);
855 data_size = sizeof(struct lio_version);
856 sc = (struct octeon_soft_command *)
857 octeon_alloc_soft_command(oct, data_size,
858 resp_size, ctx_size);
859 if (!sc) {
860 dev_err(&oct->pci_dev->dev, "%s: Failed to allocate soft command\n",
861 __func__);
862 return -1;
863 }
864
865 resp = (struct liquidio_if_cfg_resp *)sc->virtrptr;
866 ctx = (struct liquidio_if_cfg_context *)sc->ctxptr;
867 vdata = (struct lio_version *)sc->virtdptr;
868
> 869 vdata->major = cpu_to_be16(LIQUIDIO_BASE_MAJOR_VERSION);
> 870 vdata->minor = cpu_to_be16(LIQUIDIO_BASE_MINOR_VERSION);
> 871 vdata->micro = cpu_to_be16(LIQUIDIO_BASE_MICRO_VERSION);
872
873 ifidx_or_pfnum = oct->pf_num;
874 WRITE_ONCE(ctx->cond, 0);
875 ctx->octeon_id = lio_get_device_id(oct);
876 init_waitqueue_head(&ctx->wc);
877
878 if_cfg.u64 = 0;
879 if_cfg.s.num_iqueues = oct->sriov_info.num_pf_rings;
880 if_cfg.s.num_oqueues = oct->sriov_info.num_pf_rings;
881 if_cfg.s.base_queue = oct->sriov_info.pf_srn;
882 if_cfg.s.gmx_port_id = oct->pf_num;
883
884 sc->iq_no = 0;
885 octeon_prepare_soft_command(oct, sc, OPCODE_NIC,
886 OPCODE_NIC_QCOUNT_UPDATE, 0,
887 if_cfg.u64, 0);
888 sc->callback = lio_if_cfg_callback;
889 sc->callback_arg = sc;
890 sc->wait_time = LIO_IFCFG_WAIT_TIME;
891
892 retval = octeon_send_soft_command(oct, sc);
893 if (retval == IQ_SEND_FAILED) {
894 dev_err(&oct->pci_dev->dev,
895 "iq/oq config failed status: %x\n",
896 retval);
897 goto qcount_update_fail;
898 }
899
900 if (sleep_cond(&ctx->wc, &ctx->cond) == -EINTR) {
901 dev_err(&oct->pci_dev->dev, "Wait interrupted\n");
902 return -1;
903 }
904
905 retval = resp->status;
906 if (retval) {
907 dev_err(&oct->pci_dev->dev, "iq/oq config failed\n");
908 goto qcount_update_fail;
909 }
910
911 octeon_swap_8B_data((u64 *)(&resp->cfg_info),
912 (sizeof(struct liquidio_if_cfg_info)) >> 3);
913
914 lio->ifidx = ifidx_or_pfnum;
915 lio->linfo.num_rxpciq = hweight64(resp->cfg_info.iqmask);
916 lio->linfo.num_txpciq = hweight64(resp->cfg_info.iqmask);
917 for (j = 0; j < lio->linfo.num_rxpciq; j++) {
918 lio->linfo.rxpciq[j].u64 =
919 resp->cfg_info.linfo.rxpciq[j].u64;
920 }
921
922 for (j = 0; j < lio->linfo.num_txpciq; j++) {
923 lio->linfo.txpciq[j].u64 =
924 resp->cfg_info.linfo.txpciq[j].u64;
925 }
926
927 lio->linfo.hw_addr = resp->cfg_info.linfo.hw_addr;
928 lio->linfo.gmxport = resp->cfg_info.linfo.gmxport;
929 lio->linfo.link.u64 = resp->cfg_info.linfo.link.u64;
930 lio->txq = lio->linfo.txpciq[0].s.q_no;
931 lio->rxq = lio->linfo.rxpciq[0].s.q_no;
932
933 octeon_free_soft_command(oct, sc);
934 dev_info(&oct->pci_dev->dev, "Queue count updated to %d\n",
935 lio->linfo.num_rxpciq);
936
937 return 0;
938
939 qcount_update_fail:
940 octeon_free_soft_command(oct, sc);
941
942 return -1;
943 }
944
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [RFC PATCH] liquidio: lio_23xx_reconfigure_queue_count() can be static
From: kbuild test robot @ 2018-04-27 15:07 UTC (permalink / raw)
To: Felix Manlunas
Cc: kbuild-all, davem, netdev, raghu.vatsavayi, derek.chickles,
satananda.burla, felix.manlunas, intiyaz.basha
In-Reply-To: <20180425182350.GA13911@felix-thinkpad.cavium.com>
Fixes: a6b1f70737e0 ("liquidio: enhanced ethtool --set-channels feature")
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
lio_ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index 7ca246e..4877776d 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -837,7 +837,7 @@ lio_ethtool_get_ringparam(struct net_device *netdev,
ering->rx_jumbo_max_pending = 0;
}
-int lio_23xx_reconfigure_queue_count(struct lio *lio)
+static int lio_23xx_reconfigure_queue_count(struct lio *lio)
{
struct octeon_device *oct = lio->oct_dev;
struct liquidio_if_cfg_context *ctx;
^ permalink raw reply related
* [PATCH net-next v2 1/6] net: bridge: Publish bridge accessor functions
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: Ido Schimmel, mlxsw, nikolay, jiri, petrm, davem
In-Reply-To: <20180427151111.22099-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Add a couple new functions to allow querying FDB and vlan settings of a
bridge.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
include/linux/if_bridge.h | 28 ++++++++++++++++++++++++++++
net/bridge/br_fdb.c | 22 ++++++++++++++++++++++
net/bridge/br_private.h | 11 +++++++++++
net/bridge/br_vlan.c | 39 +++++++++++++++++++++++++++++++++++++++
4 files changed, 100 insertions(+)
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index 02639ebea2f0..769cf71efbdf 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -93,11 +93,39 @@ static inline bool br_multicast_router(const struct net_device *dev)
#if IS_ENABLED(CONFIG_BRIDGE) && IS_ENABLED(CONFIG_BRIDGE_VLAN_FILTERING)
bool br_vlan_enabled(const struct net_device *dev);
+int br_vlan_pvid_rtnl(const struct net_device *dev, u16 *p_pvid);
+int br_vlan_info_rtnl(const struct net_device *dev, u16 vid,
+ struct bridge_vlan_info *p_vinfo);
#else
static inline bool br_vlan_enabled(const struct net_device *dev)
{
return false;
}
+
+static inline int br_vlan_pvid_rtnl(const struct net_device *dev, u16 *p_pvid)
+{
+ return -1;
+}
+
+static inline int br_vlan_info_rtnl(const struct net_device *dev, u16 vid,
+ struct bridge_vlan_info *p_vinfo)
+{
+ return -1;
+}
+#endif
+
+#if IS_ENABLED(CONFIG_BRIDGE)
+struct net_device *br_fdb_find_port_rtnl(const struct net_device *br_dev,
+ const unsigned char *addr,
+ __u16 vid);
+#else
+static inline struct net_device *
+br_fdb_find_port_rtnl(const struct net_device *br_dev,
+ const unsigned char *addr,
+ __u16 vid)
+{
+ return NULL;
+}
#endif
#endif
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index d9e69e4514be..51c7720aaba9 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -121,6 +121,28 @@ static struct net_bridge_fdb_entry *br_fdb_find(struct net_bridge *br,
return fdb;
}
+struct net_device *br_fdb_find_port_rtnl(const struct net_device *br_dev,
+ const unsigned char *addr,
+ __u16 vid)
+{
+ struct net_bridge_fdb_entry *f;
+ struct net_device *dev = NULL;
+ struct net_bridge *br;
+
+ ASSERT_RTNL();
+
+ if (!netif_is_bridge_master(br_dev))
+ return NULL;
+
+ br = netdev_priv(br_dev);
+ f = br_fdb_find(br, addr, vid);
+ if (f && f->dst)
+ dev = f->dst->dev;
+
+ return dev;
+}
+EXPORT_SYMBOL_GPL(br_fdb_find_port_rtnl);
+
struct net_bridge_fdb_entry *br_fdb_find_rcu(struct net_bridge *br,
const unsigned char *addr,
__u16 vid)
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index a7cb3ece5031..1a5093115534 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -594,11 +594,22 @@ static inline bool br_rx_handler_check_rcu(const struct net_device *dev)
return rcu_dereference(dev->rx_handler) == br_handle_frame;
}
+static inline bool br_rx_handler_check_rtnl(const struct net_device *dev)
+{
+ return rcu_dereference_rtnl(dev->rx_handler) == br_handle_frame;
+}
+
static inline struct net_bridge_port *br_port_get_check_rcu(const struct net_device *dev)
{
return br_rx_handler_check_rcu(dev) ? br_port_get_rcu(dev) : NULL;
}
+static inline struct net_bridge_port *
+br_port_get_check_rtnl(const struct net_device *dev)
+{
+ return br_rx_handler_check_rtnl(dev) ? br_port_get_rtnl_rcu(dev) : NULL;
+}
+
/* br_ioctl.c */
int br_dev_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
int br_ioctl_deviceless_stub(struct net *net, unsigned int cmd,
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 9896f4975353..821014da3ef3 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -1149,3 +1149,42 @@ void br_vlan_get_stats(const struct net_bridge_vlan *v,
stats->tx_packets += txpackets;
}
}
+
+int br_vlan_pvid_rtnl(const struct net_device *dev, u16 *p_pvid)
+{
+ struct net_bridge_vlan_group *vg;
+
+ ASSERT_RTNL();
+ if (netif_is_bridge_master(dev))
+ vg = br_vlan_group(netdev_priv(dev));
+ else
+ return -EINVAL;
+
+ *p_pvid = br_get_pvid(vg);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(br_vlan_pvid_rtnl);
+
+int br_vlan_info_rtnl(const struct net_device *dev, u16 vid,
+ struct bridge_vlan_info *p_vinfo)
+{
+ struct net_bridge_vlan_group *vg;
+ struct net_bridge_vlan *v;
+ struct net_bridge_port *p;
+
+ ASSERT_RTNL();
+ p = br_port_get_check_rtnl(dev);
+ if (p)
+ vg = nbp_vlan_group(p);
+ else
+ return -EINVAL;
+
+ v = br_vlan_find(vg, vid);
+ if (!v)
+ return -ENOENT;
+
+ p_vinfo->vid = vid;
+ p_vinfo->flags = v->flags;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(br_vlan_info_rtnl);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v2 0/6] mlxsw: SPAN: Support routes pointing at bridges
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, nikolay, stephen, mlxsw, Ido Schimmel
Petr says:
When mirroring to a gretap or ip6gretap netdevice, the route that
directs the encapsulated packets can reference a bridge. In that case,
in the software model, the packet is switched.
Thus when offloading mirroring like that, take into consideration FDB,
STP, PVID configured at the bridge, and whether that VLAN ID should be
tagged on egress.
Patch #1 introduces functions to get bridge PVID, VLAN flags and to look
up an FDB entry.
Patches #2 and #3 refactor some existing code and introduce a new
accessor function.
With patches #4 and #5 mlxsw calls mlxsw_sp_span_respin() on switchdev
events as well. There is no impact yet, because bridge as an underlay
device is still not allowed.
That is implemented in patch #6, which uses the new interfaces to figure
out on which one port the mirroring should be configured, and whether
the mirrored packets should be VLAN-tagged and how.
Changes from v1 to v2:
- Change the suite of bridge accessor functions to br_vlan_pvid_rtnl(),
br_vlan_info_rtnl(), br_fdb_find_port_rtnl().
Petr Machata (6):
net: bridge: Publish bridge accessor functions
mlxsw: spectrum: Extract mlxsw_sp_stp_spms_state()
mlxsw: spectrum_switchdev: Publish two functions
mlxsw: spectrum: Register SPAN before switchdev
mlxsw: Respin SPAN on switchdev events
mlxsw: spectrum_span: Allow bridge for gretap mirror
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 50 ++++++------
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 +
.../net/ethernet/mellanox/mlxsw/spectrum_span.c | 95 ++++++++++++++++++++--
.../net/ethernet/mellanox/mlxsw/spectrum_span.h | 1 +
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 72 ++++++++++++++--
.../ethernet/mellanox/mlxsw/spectrum_switchdev.h | 43 ++++++++++
include/linux/if_bridge.h | 28 +++++++
net/bridge/br_fdb.c | 22 +++++
net/bridge/br_private.h | 11 +++
net/bridge/br_vlan.c | 39 +++++++++
10 files changed, 326 insertions(+), 36 deletions(-)
create mode 100644 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.h
--
2.14.3
^ permalink raw reply
* [PATCH net-next v2 2/6] mlxsw: spectrum: Extract mlxsw_sp_stp_spms_state()
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, nikolay, stephen, mlxsw, Ido Schimmel
In-Reply-To: <20180427151111.22099-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Instead of duplicating the decision regarding port forwarding state made
by mlxsw_sp_port_vid_stp_set(), extract the decision-making into a new
function and reuse.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 26 +++++++++++++-------------
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 +
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index ca38a30fbe91..7317fb8079d1 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -441,29 +441,29 @@ static void mlxsw_sp_txhdr_construct(struct sk_buff *skb,
mlxsw_tx_hdr_type_set(txhdr, MLXSW_TXHDR_TYPE_CONTROL);
}
-int mlxsw_sp_port_vid_stp_set(struct mlxsw_sp_port *mlxsw_sp_port, u16 vid,
- u8 state)
+enum mlxsw_reg_spms_state mlxsw_sp_stp_spms_state(u8 state)
{
- struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
- enum mlxsw_reg_spms_state spms_state;
- char *spms_pl;
- int err;
-
switch (state) {
case BR_STATE_FORWARDING:
- spms_state = MLXSW_REG_SPMS_STATE_FORWARDING;
- break;
+ return MLXSW_REG_SPMS_STATE_FORWARDING;
case BR_STATE_LEARNING:
- spms_state = MLXSW_REG_SPMS_STATE_LEARNING;
- break;
+ return MLXSW_REG_SPMS_STATE_LEARNING;
case BR_STATE_LISTENING: /* fall-through */
case BR_STATE_DISABLED: /* fall-through */
case BR_STATE_BLOCKING:
- spms_state = MLXSW_REG_SPMS_STATE_DISCARDING;
- break;
+ return MLXSW_REG_SPMS_STATE_DISCARDING;
default:
BUG();
}
+}
+
+int mlxsw_sp_port_vid_stp_set(struct mlxsw_sp_port *mlxsw_sp_port, u16 vid,
+ u8 state)
+{
+ enum mlxsw_reg_spms_state spms_state = mlxsw_sp_stp_spms_state(state);
+ struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp;
+ char *spms_pl;
+ int err;
spms_pl = kmalloc(MLXSW_REG_SPMS_LEN, GFP_KERNEL);
if (!spms_pl)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
index 804d4d2c8031..4a519d8edec8 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
@@ -364,6 +364,7 @@ int __mlxsw_sp_port_headroom_set(struct mlxsw_sp_port *mlxsw_sp_port, int mtu,
int mlxsw_sp_port_ets_maxrate_set(struct mlxsw_sp_port *mlxsw_sp_port,
enum mlxsw_reg_qeec_hr hr, u8 index,
u8 next_index, u32 maxrate);
+enum mlxsw_reg_spms_state mlxsw_sp_stp_spms_state(u8 stp_state);
int mlxsw_sp_port_vid_stp_set(struct mlxsw_sp_port *mlxsw_sp_port, u16 vid,
u8 state);
int mlxsw_sp_port_vp_mode_set(struct mlxsw_sp_port *mlxsw_sp_port, bool enable);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v2 3/6] mlxsw: spectrum_switchdev: Publish two functions
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, nikolay, stephen, mlxsw, Ido Schimmel
In-Reply-To: <20180427151111.22099-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Publish the existing function mlxsw_sp_bridge_port_find(), and add
another service accessor mlxsw_sp_bridge_port_stp_state(). Publish both
in a new file spectrum_switchdev.h.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 9 ++++-
.../ethernet/mellanox/mlxsw/spectrum_switchdev.h | 43 ++++++++++++++++++++++
2 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.h
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index c11c9a635866..db4aea0f8996 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -50,6 +50,7 @@
#include <net/switchdev.h>
#include "spectrum_router.h"
+#include "spectrum_switchdev.h"
#include "spectrum.h"
#include "core.h"
#include "reg.h"
@@ -239,7 +240,7 @@ __mlxsw_sp_bridge_port_find(const struct mlxsw_sp_bridge_device *bridge_device,
return NULL;
}
-static struct mlxsw_sp_bridge_port *
+struct mlxsw_sp_bridge_port *
mlxsw_sp_bridge_port_find(struct mlxsw_sp_bridge *bridge,
struct net_device *brport_dev)
{
@@ -2297,6 +2298,12 @@ static struct notifier_block mlxsw_sp_switchdev_notifier = {
.notifier_call = mlxsw_sp_switchdev_event,
};
+u8
+mlxsw_sp_bridge_port_stp_state(struct mlxsw_sp_bridge_port *bridge_port)
+{
+ return bridge_port->stp_state;
+}
+
static int mlxsw_sp_fdb_init(struct mlxsw_sp *mlxsw_sp)
{
struct mlxsw_sp_bridge *bridge = mlxsw_sp->bridge;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.h
new file mode 100644
index 000000000000..bc44d5effc28
--- /dev/null
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
+ * drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.h
+ * Copyright (c) 2018 Mellanox Technologies. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * 3. Neither the names of the copyright holders nor the names of its
+ * contributors may be used to endorse or promote products derived from
+ * this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include <linux/netdevice.h>
+
+struct mlxsw_sp_bridge;
+struct mlxsw_sp_bridge_port;
+
+struct mlxsw_sp_bridge_port *
+mlxsw_sp_bridge_port_find(struct mlxsw_sp_bridge *bridge,
+ struct net_device *brport_dev);
+
+u8 mlxsw_sp_bridge_port_stp_state(struct mlxsw_sp_bridge_port *bridge_port);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v2 4/6] mlxsw: spectrum: Register SPAN before switchdev
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, nikolay, stephen, mlxsw, Ido Schimmel
In-Reply-To: <20180427151111.22099-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Since switchdev events can trigger SPAN respin, it is necessary that the
data structures are available. Register SPAN first, with a commentary on
what the dependencies are.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 7317fb8079d1..94132f6cec61 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -3666,6 +3666,15 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
goto err_lag_init;
}
+ /* Initialize SPAN before router and switchdev, so that those components
+ * can call mlxsw_sp_span_respin().
+ */
+ err = mlxsw_sp_span_init(mlxsw_sp);
+ if (err) {
+ dev_err(mlxsw_sp->bus_info->dev, "Failed to init span system\n");
+ goto err_span_init;
+ }
+
err = mlxsw_sp_switchdev_init(mlxsw_sp);
if (err) {
dev_err(mlxsw_sp->bus_info->dev, "Failed to initialize switchdev\n");
@@ -3684,15 +3693,6 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
goto err_afa_init;
}
- err = mlxsw_sp_span_init(mlxsw_sp);
- if (err) {
- dev_err(mlxsw_sp->bus_info->dev, "Failed to init span system\n");
- goto err_span_init;
- }
-
- /* Initialize router after SPAN is initialized, so that the FIB and
- * neighbor event handlers can issue SPAN respin.
- */
err = mlxsw_sp_router_init(mlxsw_sp);
if (err) {
dev_err(mlxsw_sp->bus_info->dev, "Failed to initialize router\n");
@@ -3739,14 +3739,14 @@ static int mlxsw_sp_init(struct mlxsw_core *mlxsw_core,
err_netdev_notifier:
mlxsw_sp_router_fini(mlxsw_sp);
err_router_init:
- mlxsw_sp_span_fini(mlxsw_sp);
-err_span_init:
mlxsw_sp_afa_fini(mlxsw_sp);
err_afa_init:
mlxsw_sp_counter_pool_fini(mlxsw_sp);
err_counter_pool_init:
mlxsw_sp_switchdev_fini(mlxsw_sp);
err_switchdev_init:
+ mlxsw_sp_span_fini(mlxsw_sp);
+err_span_init:
mlxsw_sp_lag_fini(mlxsw_sp);
err_lag_init:
mlxsw_sp_buffers_fini(mlxsw_sp);
@@ -3768,10 +3768,10 @@ static void mlxsw_sp_fini(struct mlxsw_core *mlxsw_core)
mlxsw_sp_acl_fini(mlxsw_sp);
unregister_netdevice_notifier(&mlxsw_sp->netdevice_nb);
mlxsw_sp_router_fini(mlxsw_sp);
- mlxsw_sp_span_fini(mlxsw_sp);
mlxsw_sp_afa_fini(mlxsw_sp);
mlxsw_sp_counter_pool_fini(mlxsw_sp);
mlxsw_sp_switchdev_fini(mlxsw_sp);
+ mlxsw_sp_span_fini(mlxsw_sp);
mlxsw_sp_lag_fini(mlxsw_sp);
mlxsw_sp_buffers_fini(mlxsw_sp);
mlxsw_sp_traps_fini(mlxsw_sp);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next v2 5/6] mlxsw: Respin SPAN on switchdev events
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, nikolay, stephen, mlxsw, Ido Schimmel
In-Reply-To: <20180427151111.22099-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
Changes to switchdev artifact can make a SPAN entry offloadable or
unoffloadable. To that end:
- Listen to SWITCHDEV_FDB_*_TO_BRIDGE notifications in addition to
the *_TO_DEVICE ones, to catch whatever activity is sent to the
bridge (likely by mlxsw itself).
On each FDB notification, respin SPAN to reconcile it with the FDB
changes.
- Also respin on switchdev port attribute changes (which currently
covers changes to STP state of ports) and port object additions and
removals.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 63 ++++++++++++++++++++--
1 file changed, 59 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index db4aea0f8996..1af99fe5fd32 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -49,6 +49,7 @@
#include <linux/netlink.h>
#include <net/switchdev.h>
+#include "spectrum_span.h"
#include "spectrum_router.h"
#include "spectrum_switchdev.h"
#include "spectrum.h"
@@ -923,6 +924,9 @@ static int mlxsw_sp_port_attr_set(struct net_device *dev,
break;
}
+ if (switchdev_trans_ph_commit(trans))
+ mlxsw_sp_span_respin(mlxsw_sp_port->mlxsw_sp);
+
return err;
}
@@ -1647,18 +1651,57 @@ mlxsw_sp_port_mrouter_update_mdb(struct mlxsw_sp_port *mlxsw_sp_port,
}
}
+struct mlxsw_sp_span_respin_work {
+ struct work_struct work;
+ struct mlxsw_sp *mlxsw_sp;
+};
+
+static void mlxsw_sp_span_respin_work(struct work_struct *work)
+{
+ struct mlxsw_sp_span_respin_work *respin_work =
+ container_of(work, struct mlxsw_sp_span_respin_work, work);
+
+ rtnl_lock();
+ mlxsw_sp_span_respin(respin_work->mlxsw_sp);
+ rtnl_unlock();
+ kfree(respin_work);
+}
+
+static void mlxsw_sp_span_respin_schedule(struct mlxsw_sp *mlxsw_sp)
+{
+ struct mlxsw_sp_span_respin_work *respin_work;
+
+ respin_work = kzalloc(sizeof(*respin_work), GFP_ATOMIC);
+ if (!respin_work)
+ return;
+
+ INIT_WORK(&respin_work->work, mlxsw_sp_span_respin_work);
+ respin_work->mlxsw_sp = mlxsw_sp;
+
+ mlxsw_core_schedule_work(&respin_work->work);
+}
+
static int mlxsw_sp_port_obj_add(struct net_device *dev,
const struct switchdev_obj *obj,
struct switchdev_trans *trans)
{
struct mlxsw_sp_port *mlxsw_sp_port = netdev_priv(dev);
+ const struct switchdev_obj_port_vlan *vlan;
int err = 0;
switch (obj->id) {
case SWITCHDEV_OBJ_ID_PORT_VLAN:
- err = mlxsw_sp_port_vlans_add(mlxsw_sp_port,
- SWITCHDEV_OBJ_PORT_VLAN(obj),
- trans);
+ vlan = SWITCHDEV_OBJ_PORT_VLAN(obj);
+ err = mlxsw_sp_port_vlans_add(mlxsw_sp_port, vlan, trans);
+
+ if (switchdev_trans_ph_commit(trans)) {
+ /* The event is emitted before the changes are actually
+ * applied to the bridge. Therefore schedule the respin
+ * call for later, so that the respin logic sees the
+ * updated bridge state.
+ */
+ mlxsw_sp_span_respin_schedule(mlxsw_sp_port->mlxsw_sp);
+ }
break;
case SWITCHDEV_OBJ_ID_PORT_MDB:
err = mlxsw_sp_port_mdb_add(mlxsw_sp_port,
@@ -1809,6 +1852,8 @@ static int mlxsw_sp_port_obj_del(struct net_device *dev,
break;
}
+ mlxsw_sp_span_respin(mlxsw_sp_port->mlxsw_sp);
+
return err;
}
@@ -2236,8 +2281,16 @@ static void mlxsw_sp_switchdev_event_work(struct work_struct *work)
fdb_info = &switchdev_work->fdb_info;
mlxsw_sp_port_fdb_set(mlxsw_sp_port, fdb_info, false);
break;
+ case SWITCHDEV_FDB_ADD_TO_BRIDGE: /* fall through */
+ case SWITCHDEV_FDB_DEL_TO_BRIDGE:
+ /* These events are only used to potentially update an existing
+ * SPAN mirror.
+ */
+ break;
}
+ mlxsw_sp_span_respin(mlxsw_sp_port->mlxsw_sp);
+
out:
rtnl_unlock();
kfree(switchdev_work->fdb_info.addr);
@@ -2266,7 +2319,9 @@ static int mlxsw_sp_switchdev_event(struct notifier_block *unused,
switch (event) {
case SWITCHDEV_FDB_ADD_TO_DEVICE: /* fall through */
- case SWITCHDEV_FDB_DEL_TO_DEVICE:
+ case SWITCHDEV_FDB_DEL_TO_DEVICE: /* fall through */
+ case SWITCHDEV_FDB_ADD_TO_BRIDGE: /* fall through */
+ case SWITCHDEV_FDB_DEL_TO_BRIDGE:
memcpy(&switchdev_work->fdb_info, ptr,
sizeof(switchdev_work->fdb_info));
switchdev_work->fdb_info.addr = kzalloc(ETH_ALEN, GFP_ATOMIC);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next] udp: remove stray export symbol
From: Willem de Bruijn @ 2018-04-27 15:12 UTC (permalink / raw)
To: netdev; +Cc: davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
UDP GSO needs to export __udp_gso_segment to call it from ipv6.
I accidentally exported static ipv4 function __udp4_gso_segment.
Remove that EXPORT_SYMBOL_GPL.
Fixes: ee80d1ebe5ba ("udp: add udp gso")
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/ipv4/udp_offload.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index dc5158cba66e..f78fb3673472 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -247,7 +247,6 @@ static struct sk_buff *__udp4_gso_segment(struct sk_buff *gso_skb,
udp_v4_check(sizeof(struct udphdr) + mss,
iph->saddr, iph->daddr, 0));
}
-EXPORT_SYMBOL_GPL(__udp4_gso_segment);
static struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,
netdev_features_t features)
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH net-next v2 6/6] mlxsw: spectrum_span: Allow bridge for gretap mirror
From: Ido Schimmel @ 2018-04-27 15:11 UTC (permalink / raw)
To: netdev, bridge; +Cc: davem, jiri, petrm, nikolay, stephen, mlxsw, Ido Schimmel
In-Reply-To: <20180427151111.22099-1-idosch@mellanox.com>
From: Petr Machata <petrm@mellanox.com>
When handling mirroring to a gretap or ip6gretap netdevice in mlxsw, the
underlay address (i.e. the remote address of the tunnel) may be routed
to a bridge.
In that case, look up the resolved neighbor Ethernet address in that
bridge's FDB. Then configure the offload to direct the mirrored traffic
to that port, possibly with tagging.
Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../net/ethernet/mellanox/mlxsw/spectrum_span.c | 95 ++++++++++++++++++++--
.../net/ethernet/mellanox/mlxsw/spectrum_span.h | 1 +
2 files changed, 90 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
index 65a77708ff61..adac4304dad5 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.c
@@ -32,6 +32,7 @@
* POSSIBILITY OF SUCH DAMAGE.
*/
+#include <linux/if_bridge.h>
#include <linux/list.h>
#include <net/arp.h>
#include <net/gre.h>
@@ -39,8 +40,9 @@
#include <net/ip6_tunnel.h>
#include "spectrum.h"
-#include "spectrum_span.h"
#include "spectrum_ipip.h"
+#include "spectrum_span.h"
+#include "spectrum_switchdev.h"
int mlxsw_sp_span_init(struct mlxsw_sp *mlxsw_sp)
{
@@ -167,6 +169,72 @@ mlxsw_sp_span_entry_unoffloadable(struct mlxsw_sp_span_parms *sparmsp)
return 0;
}
+static struct net_device *
+mlxsw_sp_span_entry_bridge_8021q(const struct net_device *br_dev,
+ unsigned char *dmac,
+ u16 *p_vid)
+{
+ struct bridge_vlan_info vinfo;
+ struct net_device *edev;
+ u16 pvid;
+
+ if (WARN_ON(br_vlan_pvid_rtnl(br_dev, &pvid)))
+ return NULL;
+ if (!pvid)
+ return NULL;
+
+ edev = br_fdb_find_port_rtnl(br_dev, dmac, pvid);
+ if (!edev)
+ return NULL;
+
+ if (br_vlan_info_rtnl(edev, pvid, &vinfo))
+ return NULL;
+ if (!(vinfo.flags & BRIDGE_VLAN_INFO_UNTAGGED))
+ *p_vid = pvid;
+ return edev;
+}
+
+static struct net_device *
+mlxsw_sp_span_entry_bridge_8021d(const struct net_device *br_dev,
+ unsigned char *dmac)
+{
+ return br_fdb_find_port_rtnl(br_dev, dmac, 0);
+}
+
+static struct net_device *
+mlxsw_sp_span_entry_bridge(const struct net_device *br_dev,
+ unsigned char dmac[ETH_ALEN],
+ u16 *p_vid)
+{
+ struct mlxsw_sp_bridge_port *bridge_port;
+ enum mlxsw_reg_spms_state spms_state;
+ struct mlxsw_sp_port *port;
+ struct net_device *dev;
+ u8 stp_state;
+
+ if (br_vlan_enabled(br_dev))
+ dev = mlxsw_sp_span_entry_bridge_8021q(br_dev, dmac, p_vid);
+ else
+ dev = mlxsw_sp_span_entry_bridge_8021d(br_dev, dmac);
+ if (!dev)
+ return NULL;
+
+ port = mlxsw_sp_port_dev_lower_find(dev);
+ if (!port)
+ return NULL;
+
+ bridge_port = mlxsw_sp_bridge_port_find(port->mlxsw_sp->bridge, dev);
+ if (!bridge_port)
+ return NULL;
+
+ stp_state = mlxsw_sp_bridge_port_stp_state(bridge_port);
+ spms_state = mlxsw_sp_stp_spms_state(stp_state);
+ if (spms_state != MLXSW_REG_SPMS_STATE_FORWARDING)
+ return NULL;
+
+ return dev;
+}
+
static __maybe_unused int
mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *l3edev,
union mlxsw_sp_l3addr saddr,
@@ -177,13 +245,22 @@ mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *l3edev,
struct mlxsw_sp_span_parms *sparmsp)
{
unsigned char dmac[ETH_ALEN];
+ u16 vid = 0;
if (mlxsw_sp_l3addr_is_zero(gw))
gw = daddr;
- if (!l3edev || !mlxsw_sp_port_dev_check(l3edev) ||
- mlxsw_sp_span_dmac(tbl, &gw, l3edev, dmac))
- return mlxsw_sp_span_entry_unoffloadable(sparmsp);
+ if (!l3edev || mlxsw_sp_span_dmac(tbl, &gw, l3edev, dmac))
+ goto unoffloadable;
+
+ if (netif_is_bridge_master(l3edev)) {
+ l3edev = mlxsw_sp_span_entry_bridge(l3edev, dmac, &vid);
+ if (!l3edev)
+ goto unoffloadable;
+ }
+
+ if (!mlxsw_sp_port_dev_check(l3edev))
+ goto unoffloadable;
sparmsp->dest_port = netdev_priv(l3edev);
sparmsp->ttl = ttl;
@@ -191,7 +268,11 @@ mlxsw_sp_span_entry_tunnel_parms_common(struct net_device *l3edev,
memcpy(sparmsp->smac, l3edev->dev_addr, ETH_ALEN);
sparmsp->saddr = saddr;
sparmsp->daddr = daddr;
+ sparmsp->vid = vid;
return 0;
+
+unoffloadable:
+ return mlxsw_sp_span_entry_unoffloadable(sparmsp);
}
#if IS_ENABLED(CONFIG_NET_IPGRE)
@@ -268,9 +349,10 @@ mlxsw_sp_span_entry_gretap4_configure(struct mlxsw_sp_span_entry *span_entry,
/* Create a new port analayzer entry for local_port. */
mlxsw_reg_mpat_pack(mpat_pl, pa_id, local_port, true,
MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH_L3);
+ mlxsw_reg_mpat_eth_rspan_pack(mpat_pl, sparms.vid);
mlxsw_reg_mpat_eth_rspan_l2_pack(mpat_pl,
MLXSW_REG_MPAT_ETH_RSPAN_VERSION_NO_HEADER,
- sparms.dmac, false);
+ sparms.dmac, !!sparms.vid);
mlxsw_reg_mpat_eth_rspan_l3_ipv4_pack(mpat_pl,
sparms.ttl, sparms.smac,
be32_to_cpu(sparms.saddr.addr4),
@@ -368,9 +450,10 @@ mlxsw_sp_span_entry_gretap6_configure(struct mlxsw_sp_span_entry *span_entry,
/* Create a new port analayzer entry for local_port. */
mlxsw_reg_mpat_pack(mpat_pl, pa_id, local_port, true,
MLXSW_REG_MPAT_SPAN_TYPE_REMOTE_ETH_L3);
+ mlxsw_reg_mpat_eth_rspan_pack(mpat_pl, sparms.vid);
mlxsw_reg_mpat_eth_rspan_l2_pack(mpat_pl,
MLXSW_REG_MPAT_ETH_RSPAN_VERSION_NO_HEADER,
- sparms.dmac, false);
+ sparms.dmac, !!sparms.vid);
mlxsw_reg_mpat_eth_rspan_l3_ipv6_pack(mpat_pl, sparms.ttl, sparms.smac,
sparms.saddr.addr6,
sparms.daddr.addr6);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.h
index 4b87ec20e658..14a6de904db1 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_span.h
@@ -63,6 +63,7 @@ struct mlxsw_sp_span_parms {
unsigned char smac[ETH_ALEN];
union mlxsw_sp_l3addr daddr;
union mlxsw_sp_l3addr saddr;
+ u16 vid;
};
struct mlxsw_sp_span_entry_ops;
--
2.14.3
^ permalink raw reply related
* Re: [PATCH net] nfp: don't depend on eth_tbl being available
From: David Miller @ 2018-04-27 15:15 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev, oss-drivers
In-Reply-To: <20180425182108.31363-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Wed, 25 Apr 2018 11:21:08 -0700
> For very very old generation of the management FW Ethernet port
> information table may theoretically not be available. This in
> turn will cause the nfp_port structures to not be allocated.
>
> Make sure we don't crash the kernel when there is no eth_tbl:
>
> RIP: 0010:nfp_net_pci_probe+0xf2/0xb40 [nfp]
> ...
> Call Trace:
> nfp_pci_probe+0x6de/0xab0 [nfp]
> local_pci_probe+0x47/0xa0
> work_for_cpu_fn+0x1a/0x30
> process_one_work+0x1de/0x3e0
>
> Found while working with broken/development version of management FW.
>
> Fixes: a5950182c00e ("nfp: map mac_stats and vf_cfg BARs")
> Fixes: 93da7d9660ee ("nfp: provide nfp_port to of nfp_net_get_mac_addr()")
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Applied, thanks Jakub.
Do you want this queued up for -stable? It seems borderline, at best, to me.
^ permalink raw reply
* [PATCH] net/mlx4_core: Fix error handling in mlx4_init_port_info.
From: Tarick Bedeir @ 2018-04-27 15:20 UTC (permalink / raw)
To: tariqt, gthelen, netdev, linux-rdma, linux-kernel, tarick
Cc: Greg Thelen, netdev, linux-rdma, linux-kernel, Tarick Bedeir
Avoid exiting the function with a lingering sysfs file (if the first
call to device_create_file() fails while the second succeeds), and avoid
calling devlink_port_unregister() twice.
In other words, either mlx4_init_port_info() succeeds and returns zero, or
it fails, returns non-zero, and requires no cleanup.
Signed-off-by: Tarick Bedeir <tarick@google.com>
---
drivers/net/ethernet/mellanox/mlx4/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 4d84cab77105..e8a3a45d0b53 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -3007,6 +3007,7 @@ static int mlx4_init_port_info(struct mlx4_dev *dev, int port)
mlx4_err(dev, "Failed to create file for port %d\n", port);
devlink_port_unregister(&info->devlink_port);
info->port = -1;
+ return err;
}
sprintf(info->dev_mtu_name, "mlx4_port%d_mtu", port);
@@ -3028,9 +3029,10 @@ static int mlx4_init_port_info(struct mlx4_dev *dev, int port)
&info->port_attr);
devlink_port_unregister(&info->devlink_port);
info->port = -1;
+ return err;
}
- return err;
+ return 0;
}
static void mlx4_cleanup_port_info(struct mlx4_port_info *info)
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* Re: [PATCH net v2 0/2] net: mvpp2: Fix hangs when starting some interfaces on 7k/8k
From: David Miller @ 2018-04-27 15:23 UTC (permalink / raw)
To: maxime.chevallier
Cc: netdev, linux-kernel, antoine.tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw,
linux, linux-arm-kernel
In-Reply-To: <20180425182117.28826-1-maxime.chevallier@bootlin.com>
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date: Wed, 25 Apr 2018 20:21:15 +0200
> Armada 7K / 8K clock management has recently been reworked, see :
>
> commit c7e92def1ef4 ("clk: mvebu: cp110: Fix clock tree representation")
>
> I have been experiencing overall system hangs on MacchiatoBin when starting
> the eth1 interface since then. It turns out some clocks dependencies were
> missing in the PPv2 and xmdio driver, the clock rework made this visible.
>
> This is the V2 series, that adds support for the missing 'MG Core clock' in
> mvpp2, and fixes an issue with the error path for the axi_clk.
>
> Thanks to Gregory Clement for finding the root cause of this bug.
>
> V2 : Remove all DT patches from this series, they will be merged through
> the mvebu tree.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/6] liquidio: enhanced ethtool --set-channels feature
From: David Miller @ 2018-04-27 15:24 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
intiyaz.basha
In-Reply-To: <20180425182301.GA13840@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Wed, 25 Apr 2018 11:23:01 -0700
> From: Intiyaz Basha <intiyaz.basha@cavium.com>
>
> For the ethtool --set-channels feature, the liquidio driver currently
> accepts max combined value as the queue count configured during driver
> load time, where max combined count is the total count of input and output
> queues. This limitation is applicable only when SR-IOV is enabled, that
> is, when VFs are created for PF. If SR-IOV is not enabled, the driver can
> configure max supported (64) queues.
>
> This series of patches are for enhancing driver to accept
> max supported queues for ethtool --set-channels.
Looks like patch #6 needs some warning fixes as per kbuild robot.
^ permalink raw reply
* Re: [PATCH net-next v2 1/6] net: bridge: Publish bridge accessor functions
From: Nikolay Aleksandrov @ 2018-04-27 15:38 UTC (permalink / raw)
To: Ido Schimmel, netdev, bridge; +Cc: davem, jiri, petrm, stephen, mlxsw
In-Reply-To: <20180427151111.22099-2-idosch@mellanox.com>
On 27/04/18 18:11, Ido Schimmel wrote:
> From: Petr Machata <petrm@mellanox.com>
>
> Add a couple new functions to allow querying FDB and vlan settings of a
> bridge.
>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> ---
> include/linux/if_bridge.h | 28 ++++++++++++++++++++++++++++
> net/bridge/br_fdb.c | 22 ++++++++++++++++++++++
> net/bridge/br_private.h | 11 +++++++++++
> net/bridge/br_vlan.c | 39 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 100 insertions(+)
>
Thanks! This looks good to me although the new exported helpers could've
taken both bridge or port and return the result. Usually when adding a
port-only functions we name them with nbp_ prefix instead of br_.
Anyway this can be done later since the API is internal,
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH net] pppoe: check sockaddr length in pppoe_connect()
From: Guillaume Nault @ 2018-04-27 15:39 UTC (permalink / raw)
To: Kevin Easton; +Cc: netdev, Michal Ostrowski
In-Reply-To: <20180427122316.GA20688@la.guarana.org>
On Fri, Apr 27, 2018 at 08:23:16AM -0400, Kevin Easton wrote:
> On Mon, Apr 23, 2018 at 04:38:27PM +0200, Guillaume Nault wrote:
> > We must validate sockaddr_len, otherwise userspace can pass fewer data
> > than we expect and we end up accessing invalid data.
> >
> > Fixes: 224cf5ad14c0 ("ppp: Move the PPP drivers")
> > Reported-by: syzbot+4f03bdf92fdf9ef5ddab@syzkaller.appspotmail.com
> > Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
> > ---
> > drivers/net/ppp/pppoe.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
> > index 1483bc7b01e1..7df07337d69c 100644
> > --- a/drivers/net/ppp/pppoe.c
> > +++ b/drivers/net/ppp/pppoe.c
> > @@ -620,6 +620,10 @@ static int pppoe_connect(struct socket *sock, struct sockaddr *uservaddr,
> > lock_sock(sk);
> >
> > error = -EINVAL;
> > +
> > + if (sockaddr_len != sizeof(struct sockaddr_pppox))
> > + goto end;
> > +
> > if (sp->sa_protocol != PX_PROTO_OE)
> > goto end;
>
> There's another bug here - pppoe_connect() should also be validating
> sp->sa_family. My suggested patch was going to be:
>
> diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
> index 1483bc7..90eb3fd 100644
> --- a/drivers/net/ppp/pppoe.c
> +++ b/drivers/net/ppp/pppoe.c
> @@ -620,6 +620,14 @@ static int pppoe_connect(struct socket *sock, struct sockaddr *uservaddr,
> lock_sock(sk);
>
> error = -EINVAL;
> + if (sockaddr_len < sizeof(struct sockaddr_pppox))
> + goto end;
> +
> + error = -EAFNOSUPPORT;
> + if (sp->sa_family != AF_PPPOX)
> + goto end;
> +
> + error = -EINVAL;
> if (sp->sa_protocol != PX_PROTO_OE)
> goto end;
>
> Should I rework this on top of net.git HEAD?
>
> (The same applies to pppol2tp_connect()).
>
Thanks for the suggestion. But ->sa_family has never been checked.
Therefore, it has always been possible to connect a PPPoE or L2TP
socket with an invalid .sa_family field. I'd be surprised if there were
implementations relying on that, but we never know (for example, an
implementation could send this field uninitialised). By being stricter
we'd break such programs. And we don't need this field in the
connection process, so not checking its value doesn't harm.
I'm all for being strict and validating user-provided data as much as
possible, but I'm afraid its too late in this case.
^ permalink raw reply
* Re: [PATCH net-next v2 6/6] mlxsw: spectrum_span: Allow bridge for gretap mirror
From: Nikolay Aleksandrov @ 2018-04-27 15:39 UTC (permalink / raw)
To: Ido Schimmel, netdev, bridge; +Cc: davem, jiri, petrm, stephen, mlxsw
In-Reply-To: <20180427151111.22099-7-idosch@mellanox.com>
On 27/04/18 18:11, Ido Schimmel wrote:
> From: Petr Machata <petrm@mellanox.com>
>
> When handling mirroring to a gretap or ip6gretap netdevice in mlxsw, the
> underlay address (i.e. the remote address of the tunnel) may be routed
> to a bridge.
>
> In that case, look up the resolved neighbor Ethernet address in that
> bridge's FDB. Then configure the offload to direct the mirrored traffic
> to that port, possibly with tagging.
>
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> ---
> .../net/ethernet/mellanox/mlxsw/spectrum_span.c | 95 ++++++++++++++++++++--
> .../net/ethernet/mellanox/mlxsw/spectrum_span.h | 1 +
> 2 files changed, 90 insertions(+), 6 deletions(-)
>
Looks good, thanks!
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCH net-next] l2tp: consistent reference counting in procfs and debufs
From: Guillaume Nault @ 2018-04-27 15:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jchapman
In-Reply-To: <20180427.110655.2017347091283412542.davem@davemloft.net>
On Fri, Apr 27, 2018 at 11:06:55AM -0400, David Miller wrote:
> From: Guillaume Nault <g.nault@alphalink.fr>
> Date: Wed, 25 Apr 2018 19:54:14 +0200
>
> > The 'pppol2tp' procfs and 'l2tp/tunnels' debugfs files handle reference
> > counting of sessions differently than for tunnels.
> >
> > For consistency, use the same mechanism for handling both sessions and
> > tunnels. That is, drop the reference on the previous session just
> > before looking up the next one (rather than in .show()). If necessary
> > (if dump stops before *_next_session() returns NULL), drop the last
> > reference in .stop().
> >
> > Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
>
> Applied.
>
> Your continued bug fixing and clenaups in this area are very much appreciated.
Nice to see that it's appreciated. Thanks!
^ permalink raw reply
* Re: ip6-in-ip{4,6} ipsec tunnel issues with 1280 MTU
From: Ashwanth Goli @ 2018-04-27 15:44 UTC (permalink / raw)
To: David Ahern; +Cc: Paolo Abeni, netdev, maloney, edumazet, netdev-owner
In-Reply-To: <b5b26603-199b-66e3-0576-ec4dfab9230f@gmail.com>
On 2018-04-27 20:18, David Ahern wrote:
> On 4/27/18 5:02 AM, Ashwanth Goli wrote:
>> On 2018-04-26 17:21, Paolo Abeni wrote:
>>> Hi,
>>>
>>> [fixed CC list]
>>>
>>> On Wed, 2018-04-25 at 21:43 +0530, Ashwanth Goli wrote:
>>>> Hi Pablo,
>>>
>>> Actually I'm Paolo, but yours is a recurring mistake ;)
>>>
>>>> I am noticing an issue similar to the one reported by Alexis Perez
>>>> [Regression for ip6-in-ip4 IPsec tunnel in 4.14.16]
>>>>
>>>> In my IPsec setup outer MTU is set to 1280, ip6_setup_cork sees an
>>>> MTU
>>>> less than IPV6_MIN_MTU because of the tunnel headers. -EINVAL is
>>>> being
>>>> returned as a result of the MTU check that got added with below
>>>> patch.
>
> If you know you are running ipsec over the link why are you setting the
> outer MTU to 1280? RFC 2460 suggests the fragmentation of packets for
> links with MTU < 1280 should be done below the IPv6 layer:
>
> 5. Packet Size Issues
>
> IPv6 requires that every link in the internet have an MTU of 1280
> octets or greater. On any link that cannot convey a 1280-octet
> packet in one piece, link-specific fragmentation and reassembly must
> be provided at a layer below IPv6.
>
> Links that have a configurable MTU (for example, PPP links [RFC-
> 1661]) must be configured to have an MTU of at least 1280 octets; it
> is recommended that they be configured with an MTU of 1500 octets or
> greater, to accommodate possible encapsulations (i.e., tunneling)
> without incurring IPv6-layer fragmentation.
But is this not breaking point (b) from section 7.1 of RFC2473 since the
inner packet can be smaller than 1280.
https://tools.ietf.org/html/rfc2473#section-7.1
^ permalink raw reply
* [PATCH net] vhost: Use kzalloc() to allocate vhost_msg_node
From: Kevin Easton @ 2018-04-27 15:45 UTC (permalink / raw)
To: Michael S. Tsirkin, Jason Wang, kvm, virtualization, netdev,
linux-kernel, syzkaller-bugs
In-Reply-To: <000000000000a5b2b1056a86e98c@google.com>
The struct vhost_msg within struct vhost_msg_node is copied to userspace,
so it should be allocated with kzalloc() to ensure all structure padding
is zeroed.
Signed-off-by: Kevin Easton <kevin@guarana.org>
Reported-by: syzbot+87cfa083e727a224754b@syzkaller.appspotmail.com
---
drivers/vhost/vhost.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index f3bd8e9..1b84dcff 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2339,7 +2339,7 @@ EXPORT_SYMBOL_GPL(vhost_disable_notify);
/* Create a new message. */
struct vhost_msg_node *vhost_new_msg(struct vhost_virtqueue *vq, int type)
{
- struct vhost_msg_node *node = kmalloc(sizeof *node, GFP_KERNEL);
+ struct vhost_msg_node *node = kzalloc(sizeof *node, GFP_KERNEL);
if (!node)
return NULL;
node->vq = vq;
--
2.8.1
^ permalink raw reply related
* Re: [net-next] ipv6: sr: Add documentation for seg_flowlabel sysctl
From: Randy Dunlap @ 2018-04-27 15:47 UTC (permalink / raw)
To: Ahmed Abdelsalam, davem, linux-doc, netdev
In-Reply-To: <1524825344-2573-1-git-send-email-amsalam20@gmail.com>
On 04/27/2018 03:35 AM, Ahmed Abdelsalam wrote:
> This patch adds a documentation for seg_flowlabel sysctl into
> Documentation/networking/ip-sysctl.txt
>
> Signed-off-by: Ahmed Abdelsalam <amsalam20@gmail.com>
> ---
> Documentation/networking/ip-sysctl.txt | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
> index 5dc1a04..7528f71 100644
> --- a/Documentation/networking/ip-sysctl.txt
> +++ b/Documentation/networking/ip-sysctl.txt
> @@ -1428,6 +1428,19 @@ ip6frag_low_thresh - INTEGER
> ip6frag_time - INTEGER
> Time in seconds to keep an IPv6 fragment in memory.
>
> +IPv6 Segment Routing:
> +
> +seg6_flowlabel - INTEGER
> + Controls the behaviour of computing the flowlabel of outer
> + IPv6 header in case of SR T.encaps
> +
> + -1 set flowlabel to zero.
> + 0 copy flowlabel from Inner paceket in case of Inner IPv6
packet
> + (Set flowlabel to 0 in case IPv4/L2)
> + 1 Compute the flowlabel using seg6_make_flowlabel()
> +
> + Default is 0.
> +
> conf/default/*:
> Change the interface-specific default settings.
>
>
--
~Randy
^ permalink raw reply
* Re: [PATCH net] tcp: ignore Fast Open on repair mode
From: David Miller @ 2018-04-27 15:50 UTC (permalink / raw)
To: ycheng; +Cc: netdev, edumazet, ncardwell
In-Reply-To: <20180425183308.70232-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 25 Apr 2018 11:33:08 -0700
> The TCP repair sequence of operation is to first set the socket in
> repair mode, then inject the TCP stats into the socket with repair
> socket options, then call connect() to re-activate the socket. The
> connect syscall simply returns and set state to ESTABLISHED
> mode. As a result Fast Open is meaningless for TCP repair.
>
> However allowing sendto() system call with MSG_FASTOPEN flag half-way
> during the repair operation could unexpectedly cause data to be
> sent, before the operation finishes changing the internal TCP stats
> (e.g. MSS). This in turn triggers TCP warnings on inconsistent
> packet accounting.
>
> The fix is to simply disallow Fast Open operation once the socket
> is in the repair mode.
>
> Reported-by: syzbot <syzkaller@googlegroups.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Reviewed-by: Neal Cardwell <ncardwell@google.com>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Yuchung.
^ 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