* [PATCH 45/47] netfilter: x_tables: Add note about how to free percpu counters
From: Pablo Neira Ayuso @ 2018-03-30 11:46 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180330114619.18797-1-pablo@netfilter.org>
From: Ben Hutchings <ben.hutchings@codethink.co.uk>
Due to the way percpu counters are allocated and freed in blocks,
it is not safe to free counters individually. Currently all callers
do the right thing, but let's note this restriction.
Fixes: ae0ac0ed6fcf ("netfilter: x_tables: pack percpu counter allocations")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/x_tables.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index bac932f1c582..75cd5196b29b 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -1854,7 +1854,9 @@ EXPORT_SYMBOL_GPL(xt_proto_fini);
* to fetch the real percpu counter.
*
* To speed up allocation and improve data locality, a 4kb block is
- * allocated.
+ * allocated. Freeing any counter may free an entire block, so all
+ * counters allocated using the same state must be freed at the same
+ * time.
*
* xt_percpu_counter_alloc_state contains the base address of the
* allocated page and the current sub-offset.
--
2.11.0
^ permalink raw reply related
* [PATCH 46/47] Revert "netfilter: x_tables: ensure last rule in base chain matches underflow/policy"
From: Pablo Neira Ayuso @ 2018-03-30 11:46 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180330114619.18797-1-pablo@netfilter.org>
From: Florian Westphal <fw@strlen.de>
This reverts commit 0d7df906a0e78079a02108b06d32c3ef2238ad25.
Valdis Kletnieks reported that xtables is broken in linux-next since
0d7df906a0e78 ("netfilter: x_tables: ensure last rule in base chain
matches underflow/policy"), as kernel rejects the (well-formed) ruleset:
[ 64.402790] ip6_tables: last base chain position 1136 doesn't match underflow 1344 (hook 1)
mark_source_chains is not the correct place for such a check, as it
terminates evaluation of a chain once it sees an unconditional verdict
(following rules are known to be unreachable). It seems preferrable to
fix libiptc instead, so remove this check again.
Fixes: 0d7df906a0e78 ("netfilter: x_tables: ensure last rule in base chain matches underflow/policy")
Reported-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/ipv4/netfilter/arp_tables.c | 17 +----------------
net/ipv4/netfilter/ip_tables.c | 17 +----------------
net/ipv6/netfilter/ip6_tables.c | 17 +----------------
3 files changed, 3 insertions(+), 48 deletions(-)
diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
index f366ff1cfc19..aaafdbd15ad3 100644
--- a/net/ipv4/netfilter/arp_tables.c
+++ b/net/ipv4/netfilter/arp_tables.c
@@ -309,13 +309,10 @@ static int mark_source_chains(const struct xt_table_info *newinfo,
for (hook = 0; hook < NF_ARP_NUMHOOKS; hook++) {
unsigned int pos = newinfo->hook_entry[hook];
struct arpt_entry *e = entry0 + pos;
- unsigned int last_pos, depth;
if (!(valid_hooks & (1 << hook)))
continue;
- depth = 0;
- last_pos = pos;
/* Set initial back pointer. */
e->counters.pcnt = pos;
@@ -346,8 +343,6 @@ static int mark_source_chains(const struct xt_table_info *newinfo,
pos = e->counters.pcnt;
e->counters.pcnt = 0;
- if (depth)
- --depth;
/* We're at the start. */
if (pos == oldpos)
goto next;
@@ -372,9 +367,6 @@ static int mark_source_chains(const struct xt_table_info *newinfo,
if (!xt_find_jump_offset(offsets, newpos,
newinfo->number))
return 0;
-
- if (entry0 + newpos != arpt_next_entry(e))
- ++depth;
} else {
/* ... this is a fallthru */
newpos = pos + e->next_offset;
@@ -385,15 +377,8 @@ static int mark_source_chains(const struct xt_table_info *newinfo,
e->counters.pcnt = pos;
pos = newpos;
}
- if (depth == 0)
- last_pos = pos;
- }
-next:
- if (last_pos != newinfo->underflow[hook]) {
- pr_err_ratelimited("last base chain position %u doesn't match underflow %u (hook %u)\n",
- last_pos, newinfo->underflow[hook], hook);
- return 0;
}
+next: ;
}
return 1;
}
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index 2362ca2c9e0c..f9063513f9d1 100644
--- a/net/ipv4/netfilter/ip_tables.c
+++ b/net/ipv4/netfilter/ip_tables.c
@@ -378,13 +378,10 @@ mark_source_chains(const struct xt_table_info *newinfo,
for (hook = 0; hook < NF_INET_NUMHOOKS; hook++) {
unsigned int pos = newinfo->hook_entry[hook];
struct ipt_entry *e = entry0 + pos;
- unsigned int last_pos, depth;
if (!(valid_hooks & (1 << hook)))
continue;
- depth = 0;
- last_pos = pos;
/* Set initial back pointer. */
e->counters.pcnt = pos;
@@ -413,8 +410,6 @@ mark_source_chains(const struct xt_table_info *newinfo,
pos = e->counters.pcnt;
e->counters.pcnt = 0;
- if (depth)
- --depth;
/* We're at the start. */
if (pos == oldpos)
goto next;
@@ -439,9 +434,6 @@ mark_source_chains(const struct xt_table_info *newinfo,
if (!xt_find_jump_offset(offsets, newpos,
newinfo->number))
return 0;
-
- if (entry0 + newpos != ipt_next_entry(e))
- ++depth;
} else {
/* ... this is a fallthru */
newpos = pos + e->next_offset;
@@ -452,15 +444,8 @@ mark_source_chains(const struct xt_table_info *newinfo,
e->counters.pcnt = pos;
pos = newpos;
}
- if (depth == 0)
- last_pos = pos;
- }
-next:
- if (last_pos != newinfo->underflow[hook]) {
- pr_err_ratelimited("last base chain position %u doesn't match underflow %u (hook %u)\n",
- last_pos, newinfo->underflow[hook], hook);
- return 0;
}
+next: ;
}
return 1;
}
diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c
index 004508753abc..3c36a4c77f29 100644
--- a/net/ipv6/netfilter/ip6_tables.c
+++ b/net/ipv6/netfilter/ip6_tables.c
@@ -396,13 +396,10 @@ mark_source_chains(const struct xt_table_info *newinfo,
for (hook = 0; hook < NF_INET_NUMHOOKS; hook++) {
unsigned int pos = newinfo->hook_entry[hook];
struct ip6t_entry *e = entry0 + pos;
- unsigned int last_pos, depth;
if (!(valid_hooks & (1 << hook)))
continue;
- depth = 0;
- last_pos = pos;
/* Set initial back pointer. */
e->counters.pcnt = pos;
@@ -431,8 +428,6 @@ mark_source_chains(const struct xt_table_info *newinfo,
pos = e->counters.pcnt;
e->counters.pcnt = 0;
- if (depth)
- --depth;
/* We're at the start. */
if (pos == oldpos)
goto next;
@@ -457,9 +452,6 @@ mark_source_chains(const struct xt_table_info *newinfo,
if (!xt_find_jump_offset(offsets, newpos,
newinfo->number))
return 0;
-
- if (entry0 + newpos != ip6t_next_entry(e))
- ++depth;
} else {
/* ... this is a fallthru */
newpos = pos + e->next_offset;
@@ -470,15 +462,8 @@ mark_source_chains(const struct xt_table_info *newinfo,
e->counters.pcnt = pos;
pos = newpos;
}
- if (depth == 0)
- last_pos = pos;
- }
-next:
- if (last_pos != newinfo->underflow[hook]) {
- pr_err_ratelimited("last base chain position %u doesn't match underflow %u (hook %u)\n",
- last_pos, newinfo->underflow[hook], hook);
- return 0;
}
+next: ;
}
return 1;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 47/47] netfilter: ipset: Use is_zero_ether_addr instead of static and memcmp
From: Pablo Neira Ayuso @ 2018-03-30 11:46 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180330114619.18797-1-pablo@netfilter.org>
From: Joe Perches <joe@perches.com>
To make the test a bit clearer and to reduce object size a little.
Miscellanea:
o remove now unnecessary static const array
$ size ip_set_hash_mac.o*
text data bss dec hex filename
22822 4619 64 27505 6b71 ip_set_hash_mac.o.allyesconfig.new
22932 4683 64 27679 6c1f ip_set_hash_mac.o.allyesconfig.old
10443 1040 0 11483 2cdb ip_set_hash_mac.o.defconfig.new
10507 1040 0 11547 2d1b ip_set_hash_mac.o.defconfig.old
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/ipset/ip_set_hash_mac.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/ipset/ip_set_hash_mac.c b/net/netfilter/ipset/ip_set_hash_mac.c
index 8f004edad396..f9d5a2a1e3d0 100644
--- a/net/netfilter/ipset/ip_set_hash_mac.c
+++ b/net/netfilter/ipset/ip_set_hash_mac.c
@@ -72,9 +72,6 @@ hash_mac4_data_next(struct hash_mac4_elem *next,
#define IP_SET_PROTO_UNDEF
#include "ip_set_hash_gen.h"
-/* Zero valued element is not supported */
-static const unsigned char invalid_ether[ETH_ALEN] = { 0 };
-
static int
hash_mac4_kadt(struct ip_set *set, const struct sk_buff *skb,
const struct xt_action_param *par,
@@ -93,7 +90,7 @@ hash_mac4_kadt(struct ip_set *set, const struct sk_buff *skb,
return -EINVAL;
ether_addr_copy(e.ether, eth_hdr(skb)->h_source);
- if (memcmp(e.ether, invalid_ether, ETH_ALEN) == 0)
+ if (is_zero_ether_addr(e.ether))
return -EINVAL;
return adtfn(set, &e, &ext, &opt->ext, opt->cmdflags);
}
@@ -118,7 +115,7 @@ hash_mac4_uadt(struct ip_set *set, struct nlattr *tb[],
if (ret)
return ret;
ether_addr_copy(e.ether, nla_data(tb[IPSET_ATTR_ETHER]));
- if (memcmp(e.ether, invalid_ether, ETH_ALEN) == 0)
+ if (is_zero_ether_addr(e.ether))
return -IPSET_ERR_HASH_ELEM;
return adtfn(set, &e, &ext, &ext, flags);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] PCI: allow drivers to limit the number of VFs to 0
From: Christoph Hellwig @ 2018-03-30 11:49 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Bjorn Helgaas, linux-pci, netdev, Sathya Perla, Felix Manlunas,
alexander.duyck, john.fastabend, Jacob Keller, Donald Dutile,
oss-drivers
In-Reply-To: <20180329182231.32151-1-jakub.kicinski@netronome.com>
On Thu, Mar 29, 2018 at 11:22:31AM -0700, Jakub Kicinski wrote:
> Some user space depends on driver allowing sriov_totalvfs to be
> enabled.
I can't make sene of this sentence. Can you explain what user space
code depends on what semantics? The sriov_totalvfs file should show
up for any device supporting SR-IOV as far as I can tell.
>
> For devices which VF support depends on loaded FW we
> have the pci_sriov_{g,s}et_totalvfs() API. However, this API
> uses 0 as a special "unset" value, meaning drivers can't limit
> sriov_totalvfs to 0. Change the special value to be U16_MAX.
> Use simple min() to determine actual totalvfs.
Please use a PCI_MAX_VFS or similar define instead of plain U16_MAX or ~0.
^ permalink raw reply
* [PATCH v2 0/7] net: thunderx: implement DMAC filtering support
From: Vadim Lomovtsev @ 2018-03-30 11:59 UTC (permalink / raw)
To: sgoutham, sunil.kovvuri, rric, linux-arm-kernel, netdev,
linux-kernel, davem
Cc: dnelson, ynorov, Vadim Lomovtsev
In-Reply-To: <20180327150736.10718-1-Vadim.Lomovtsev@caviumnetworks.com>
From: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
By default CN88XX BGX accepts all incoming multicast and broadcast
packets and filtering is disabled. The nic driver doesn't provide
an ability to change such behaviour.
This series is to implement DMAC filtering management for CN88XX
nic driver allowing user to enable/disable filtering and configure
specific MAC addresses to filter traffic.
Changes from v1:
build issues:
- update code in order to address compiler warnings;
checkpatch.pl reported issues:
- update code in order to fit 80 symbols length;
- update commit descriptions in order to fit 80 symbols length;
Vadim Lomovtsev (7):
net: thunderx: move filter register related macro into proper place
net: thunderx: add MAC address filter tracking for LMAC
net: thunderx: add multicast filter management support
net: thunderx: add new messages for handle ndo_set_rx_mode callback
net: thunderx: add XCAST messages handlers for PF
net: thunderx: add workqueue control structures for handle
ndo_set_rx_mode request
net: thunderx: add ndo_set_rx_mode callback implementation for VF
drivers/net/ethernet/cavium/thunder/nic.h | 29 ++++
drivers/net/ethernet/cavium/thunder/nic_main.c | 45 ++++-
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 110 +++++++++++-
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 201 ++++++++++++++++++++--
drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 19 +-
5 files changed, 374 insertions(+), 30 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH v2 1/7] net: thunderx: move filter register related macro into proper place
From: Vadim Lomovtsev @ 2018-03-30 11:59 UTC (permalink / raw)
To: sgoutham, sunil.kovvuri, rric, linux-arm-kernel, netdev,
linux-kernel, davem
Cc: dnelson, ynorov, Vadim Lomovtsev
In-Reply-To: <20180330115953.17154-1-Vadim.Lomovtsev@caviumnetworks.com>
From: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
The ThunderX NIC has set of registers which allows to configure
filter policy for ingress packets. There are three possible regimes
of filtering multicasts, broadcasts and unicasts: accept all, reject all
and accept filter allowed only.
Current implementation has enum with all of them and two generic macro
for enabling filtering et all (CAM_ACCEPT) and enabling/disabling
broadcast packets, which also should be corrected in order to represent
register bits properly. All these values are private for driver and
there is no need to ‘publish’ them via header file.
This commit is to move filtering register manipulation values from
header file into source with explicit assignment of exact register
values to them to be used while register configuring.
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 13 +++++++++++++
drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 11 -----------
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 91d34ea40e2c..0dd211605eb1 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -24,6 +24,19 @@
#define DRV_NAME "thunder_bgx"
#define DRV_VERSION "1.0"
+/* RX_DMAC_CTL configuration */
+enum MCAST_MODE {
+ MCAST_MODE_REJECT = 0x0,
+ MCAST_MODE_ACCEPT = 0x1,
+ MCAST_MODE_CAM_FILTER = 0x2,
+ RSVD = 0x3
+};
+
+#define BCAST_ACCEPT BIT(0)
+#define CAM_ACCEPT BIT(3)
+#define MCAST_MODE_MASK 0x3
+#define BGX_MCAST_MODE(x) (x << 1)
+
struct lmac {
struct bgx *bgx;
int dmac;
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
index 5a7567d31138..52439da62c97 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
@@ -205,17 +205,6 @@
#define LMAC_INTR_LINK_UP BIT(0)
#define LMAC_INTR_LINK_DOWN BIT(1)
-/* RX_DMAC_CTL configuration*/
-enum MCAST_MODE {
- MCAST_MODE_REJECT,
- MCAST_MODE_ACCEPT,
- MCAST_MODE_CAM_FILTER,
- RSVD
-};
-
-#define BCAST_ACCEPT 1
-#define CAM_ACCEPT 1
-
void octeon_mdiobus_force_mod_depencency(void);
void bgx_lmac_rx_tx_enable(int node, int bgx_idx, int lmacid, bool enable);
void bgx_add_dmac_addr(u64 dmac, int node, int bgx_idx, int lmac);
--
2.14.3
^ permalink raw reply related
* [PATCH v2 2/7] net: thunderx: add MAC address filter tracking for LMAC
From: Vadim Lomovtsev @ 2018-03-30 11:59 UTC (permalink / raw)
To: sgoutham, sunil.kovvuri, rric, linux-arm-kernel, netdev,
linux-kernel, davem
Cc: dnelson, ynorov, Vadim Lomovtsev
In-Reply-To: <20180330115953.17154-1-Vadim.Lomovtsev@caviumnetworks.com>
From: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
The ThunderX NIC has two Ethernet Interfaces (BGX) each of them could has
up to four Logical MACs configured. Each of BGX has 32 filters to be
configured for filtering ingress packets. The number of filters available
to particular LMAC is from 8 (if we have four LMACs configured per BGX)
up to 32 (in case of only one LMAC is configured per BGX).
At the same time the NIC could present up to 128 VFs to OS as network
interfaces, each of them kernel will configure with set of MAC addresses
for filtering. So to prevent dupes in BGX filter registers from different
network interfaces it is required to cache and track all filter
configuration requests prior to applying them onto BGX filter registers.
This commit is to update LMAC structures with control fields to
allocate/releasing filters tracking list along with implementing
dmac array allocate/release per LMAC.
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 44 +++++++++++++++--------
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 0dd211605eb1..de90e6aa5a4f 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -37,9 +37,18 @@ enum MCAST_MODE {
#define MCAST_MODE_MASK 0x3
#define BGX_MCAST_MODE(x) (x << 1)
+struct dmac_map {
+ u64 vf_map;
+ u64 dmac;
+};
+
struct lmac {
struct bgx *bgx;
- int dmac;
+ /* actual number of DMACs configured */
+ u8 dmacs_cfg;
+ /* overal number of possible DMACs could be configured per LMAC */
+ u8 dmacs_count;
+ struct dmac_map *dmacs; /* DMAC:VFs tracking filter array */
u8 mac[ETH_ALEN];
u8 lmac_type;
u8 lane_to_sds;
@@ -236,6 +245,19 @@ void bgx_set_lmac_mac(int node, int bgx_idx, int lmacid, const u8 *mac)
}
EXPORT_SYMBOL(bgx_set_lmac_mac);
+static void bgx_flush_dmac_cam_filter(struct bgx *bgx, int lmacid)
+{
+ struct lmac *lmac = NULL;
+ u8 idx = 0;
+
+ lmac = &bgx->lmac[lmacid];
+ /* reset CAM filters */
+ for (idx = 0; idx < lmac->dmacs_count; idx++)
+ bgx_reg_write(bgx, 0, BGX_CMR_RX_DMACX_CAM +
+ ((lmacid * lmac->dmacs_count) + idx) *
+ sizeof(u64), 0);
+}
+
void bgx_lmac_rx_tx_enable(int node, int bgx_idx, int lmacid, bool enable)
{
struct bgx *bgx = get_bgx(node, bgx_idx);
@@ -481,18 +503,6 @@ u64 bgx_get_tx_stats(int node, int bgx_idx, int lmac, int idx)
}
EXPORT_SYMBOL(bgx_get_tx_stats);
-static void bgx_flush_dmac_addrs(struct bgx *bgx, int lmac)
-{
- u64 offset;
-
- while (bgx->lmac[lmac].dmac > 0) {
- offset = ((bgx->lmac[lmac].dmac - 1) * sizeof(u64)) +
- (lmac * MAX_DMAC_PER_LMAC * sizeof(u64));
- bgx_reg_write(bgx, 0, BGX_CMR_RX_DMACX_CAM + offset, 0);
- bgx->lmac[lmac].dmac--;
- }
-}
-
/* Configure BGX LMAC in internal loopback mode */
void bgx_lmac_internal_loopback(int node, int bgx_idx,
int lmac_idx, bool enable)
@@ -925,6 +935,11 @@ static int bgx_lmac_enable(struct bgx *bgx, u8 lmacid)
bgx_reg_write(bgx, lmacid, BGX_SMUX_TX_MIN_PKT, 60 + 4);
}
+ /* actual number of filters available to exact LMAC */
+ lmac->dmacs_count = (RX_DMAC_COUNT / bgx->lmac_count);
+ lmac->dmacs = kcalloc(lmac->dmacs_count, sizeof(*lmac->dmacs),
+ GFP_KERNEL);
+
/* Enable lmac */
bgx_reg_modify(bgx, lmacid, BGX_CMRX_CFG, CMR_EN);
@@ -1011,7 +1026,8 @@ static void bgx_lmac_disable(struct bgx *bgx, u8 lmacid)
cfg &= ~CMR_EN;
bgx_reg_write(bgx, lmacid, BGX_CMRX_CFG, cfg);
- bgx_flush_dmac_addrs(bgx, lmacid);
+ bgx_flush_dmac_cam_filter(bgx, lmacid);
+ kfree(lmac->dmacs);
if ((lmac->lmac_type != BGX_MODE_XFI) &&
(lmac->lmac_type != BGX_MODE_XLAUI) &&
--
2.14.3
^ permalink raw reply related
* [PATCH v2 3/7] net: thunderx: add multicast filter management support
From: Vadim Lomovtsev @ 2018-03-30 11:59 UTC (permalink / raw)
To: sgoutham, sunil.kovvuri, rric, linux-arm-kernel, netdev,
linux-kernel, davem
Cc: dnelson, ynorov, Vadim Lomovtsev
In-Reply-To: <20180330115953.17154-1-Vadim.Lomovtsev@caviumnetworks.com>
From: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
The ThunderX NIC could be partitioned to up to 128 VFs and thus
represented to system. Each VF is mapped to pair BGX:LMAC, and each of VF
is configured by kernel individually. Eventually the bunch of VFs could be
mapped onto same pair BGX:LMAC and thus could cause several multicast
filtering configuration requests to LMAC with the same MAC addresses.
This commit is to add ThunderX NIC BGX filtering manipulation routines.
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 144 ++++++++++++++++++++++
drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 10 +-
2 files changed, 153 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index de90e6aa5a4f..5d08d2aeb172 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -258,6 +258,150 @@ static void bgx_flush_dmac_cam_filter(struct bgx *bgx, int lmacid)
sizeof(u64), 0);
}
+static void bgx_lmac_remove_filters(struct lmac *lmac, u8 vf_id)
+{
+ int i = 0;
+
+ if (!lmac)
+ return;
+
+ /* We've got reset filters request from some of attached VF, while the
+ * others might want to keep their configuration. So in this case lets
+ * iterate over all of configured filters and decrease number of
+ * referencies. if some addresses get zero refs remove them from list
+ */
+ for (i = lmac->dmacs_cfg - 1; i >= 0; i--) {
+ lmac->dmacs[i].vf_map &= ~BIT_ULL(vf_id);
+ if (!lmac->dmacs[i].vf_map) {
+ lmac->dmacs_cfg--;
+ lmac->dmacs[i].dmac = 0;
+ lmac->dmacs[i].vf_map = 0;
+ }
+ }
+}
+
+static int bgx_lmac_save_filter(struct lmac *lmac, u64 dmac, u8 vf_id)
+{
+ u8 i = 0;
+
+ if (!lmac)
+ return -1;
+
+ /* At the same time we could have several VFs 'attached' to some
+ * particular LMAC, and each VF is represented as network interface
+ * for kernel. So from user perspective it should be possible to
+ * manipulate with its' (VF) receive modes. However from PF
+ * driver perspective we need to keep track of filter configurations
+ * for different VFs to prevent filter values dupes
+ */
+ for (i = 0; i < lmac->dmacs_cfg; i++) {
+ if (lmac->dmacs[i].dmac == dmac) {
+ lmac->dmacs[i].vf_map |= BIT_ULL(vf_id);
+ return -1;
+ }
+ }
+
+ if (!(lmac->dmacs_cfg < lmac->dmacs_count))
+ return -1;
+
+ /* keep it for further tracking */
+ lmac->dmacs[lmac->dmacs_cfg].dmac = dmac;
+ lmac->dmacs[lmac->dmacs_cfg].vf_map = BIT_ULL(vf_id);
+ lmac->dmacs_cfg++;
+ return 0;
+}
+
+static int bgx_set_dmac_cam_filter_mac(struct bgx *bgx, int lmacid,
+ u64 cam_dmac, u8 idx)
+{
+ struct lmac *lmac = NULL;
+ u64 cfg = 0;
+
+ /* skip zero addresses as meaningless */
+ if (!cam_dmac || !bgx)
+ return -1;
+
+ lmac = &bgx->lmac[lmacid];
+
+ /* configure DCAM filtering for designated LMAC */
+ cfg = RX_DMACX_CAM_LMACID(lmacid & LMAC_ID_MASK) |
+ RX_DMACX_CAM_EN | cam_dmac;
+ bgx_reg_write(bgx, 0, BGX_CMR_RX_DMACX_CAM +
+ ((lmacid * lmac->dmacs_count) + idx) * sizeof(u64), cfg);
+ return 0;
+}
+
+void bgx_set_dmac_cam_filter(int node, int bgx_idx, int lmacid,
+ u64 cam_dmac, u8 vf_id)
+{
+ struct bgx *bgx = get_bgx(node, bgx_idx);
+ struct lmac *lmac = NULL;
+
+ if (!bgx)
+ return;
+
+ lmac = &bgx->lmac[lmacid];
+
+ if (!cam_dmac)
+ cam_dmac = ether_addr_to_u64(lmac->mac);
+
+ /* since we might have several VFs attached to particular LMAC
+ * and kernel could call mcast config for each of them with the
+ * same MAC, check if requested MAC is already in filtering list and
+ * updare/prepare list of MACs to be applied later to HW filters
+ */
+ bgx_lmac_save_filter(lmac, cam_dmac, vf_id);
+}
+EXPORT_SYMBOL(bgx_set_dmac_cam_filter);
+
+void bgx_set_xcast_mode(int node, int bgx_idx, int lmacid, u8 mode)
+{
+ struct bgx *bgx = get_bgx(node, bgx_idx);
+ struct lmac *lmac = NULL;
+ u64 cfg = 0;
+ u8 i = 0;
+
+ if (!bgx)
+ return;
+
+ lmac = &bgx->lmac[lmacid];
+
+ cfg = bgx_reg_read(bgx, lmacid, BGX_CMRX_RX_DMAC_CTL);
+ if (mode & BGX_XCAST_BCAST_ACCEPT)
+ cfg |= BCAST_ACCEPT;
+ else
+ cfg &= ~BCAST_ACCEPT;
+
+ /* disable all MCASTs and DMAC filtering */
+ cfg &= ~(CAM_ACCEPT | BGX_MCAST_MODE(MCAST_MODE_MASK));
+
+ /* check requested bits and set filtergin mode appropriately */
+ if (mode & (BGX_XCAST_MCAST_ACCEPT)) {
+ cfg |= (BGX_MCAST_MODE(MCAST_MODE_ACCEPT));
+ } else if (mode & BGX_XCAST_MCAST_FILTER) {
+ cfg |= (BGX_MCAST_MODE(MCAST_MODE_CAM_FILTER) | CAM_ACCEPT);
+ for (i = 0; i < lmac->dmacs_cfg; i++)
+ bgx_set_dmac_cam_filter_mac(bgx, lmacid,
+ lmac->dmacs[i].dmac, i);
+ }
+ bgx_reg_write(bgx, lmacid, BGX_CMRX_RX_DMAC_CTL, cfg);
+}
+EXPORT_SYMBOL(bgx_set_xcast_mode);
+
+void bgx_reset_xcast_mode(int node, int bgx_idx, int lmacid, u8 vf_id)
+{
+ struct bgx *bgx = get_bgx(node, bgx_idx);
+
+ if (!bgx)
+ return;
+
+ bgx_lmac_remove_filters(&bgx->lmac[lmacid], vf_id);
+ bgx_flush_dmac_cam_filter(bgx, lmacid);
+ bgx_set_xcast_mode(node, bgx_idx, lmacid,
+ (BGX_XCAST_BCAST_ACCEPT | BGX_XCAST_MCAST_ACCEPT));
+}
+EXPORT_SYMBOL(bgx_reset_xcast_mode);
+
void bgx_lmac_rx_tx_enable(int node, int bgx_idx, int lmacid, bool enable)
{
struct bgx *bgx = get_bgx(node, bgx_idx);
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
index 52439da62c97..cbdd20b9ee6f 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
@@ -30,6 +30,7 @@
#define DEFAULT_PAUSE_TIME 0xFFFF
#define BGX_ID_MASK 0x3
+#define LMAC_ID_MASK 0x3
#define MAX_DMAC_PER_LMAC_TNS_BYPASS_MODE 2
@@ -57,7 +58,7 @@
#define BGX_CMRX_RX_FIFO_LEN 0x108
#define BGX_CMR_RX_DMACX_CAM 0x200
#define RX_DMACX_CAM_EN BIT_ULL(48)
-#define RX_DMACX_CAM_LMACID(x) (x << 49)
+#define RX_DMACX_CAM_LMACID(x) (((u64)x) << 49)
#define RX_DMAC_COUNT 32
#define BGX_CMR_RX_STREERING 0x300
#define RX_TRAFFIC_STEER_RULE_COUNT 8
@@ -205,6 +206,13 @@
#define LMAC_INTR_LINK_UP BIT(0)
#define LMAC_INTR_LINK_DOWN BIT(1)
+#define BGX_XCAST_BCAST_ACCEPT BIT(0)
+#define BGX_XCAST_MCAST_ACCEPT BIT(1)
+#define BGX_XCAST_MCAST_FILTER BIT(2)
+
+void bgx_set_dmac_cam_filter(int node, int bgx_idx, int lmacid, u64 mac, u8 vf);
+void bgx_reset_xcast_mode(int node, int bgx_idx, int lmacid, u8 vf);
+void bgx_set_xcast_mode(int node, int bgx_idx, int lmacid, u8 mode);
void octeon_mdiobus_force_mod_depencency(void);
void bgx_lmac_rx_tx_enable(int node, int bgx_idx, int lmacid, bool enable);
void bgx_add_dmac_addr(u64 dmac, int node, int bgx_idx, int lmac);
--
2.14.3
^ permalink raw reply related
* [PATCH v2 4/7] net: thunderx: add new messages for handle ndo_set_rx_mode callback
From: Vadim Lomovtsev @ 2018-03-30 11:59 UTC (permalink / raw)
To: sgoutham, sunil.kovvuri, rric, linux-arm-kernel, netdev,
linux-kernel, davem
Cc: dnelson, ynorov, Vadim Lomovtsev
In-Reply-To: <20180330115953.17154-1-Vadim.Lomovtsev@caviumnetworks.com>
From: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
The kernel calls ndo_set_rx_mode() callback supplying it will all necessary
info, such as device state flags, multicast mac addresses list and so on.
Since we have only 128 bits to communicate with PF we need to initiate
several requests to PF with small/short operation each based on input data.
So this commit implements following PF messages codes along with new
data structures for them:
NIC_MBOX_MSG_RESET_XCAST to flush all filters configured for this
particular network interface (VF)
NIC_MBOX_MSG_ADD_MCAST to add new MAC address to DMAC filter registers
for this particular network interface (VF)
NIC_MBOX_MSG_SET_XCAST to apply filtering configuration to filter control
register
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nic.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
index 4cacce5d2b16..069289b4f968 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -403,6 +403,9 @@ struct nicvf {
#define NIC_MBOX_MSG_PTP_CFG 0x19 /* HW packet timestamp */
#define NIC_MBOX_MSG_CFG_DONE 0xF0 /* VF configuration done */
#define NIC_MBOX_MSG_SHUTDOWN 0xF1 /* VF is being shutdown */
+#define NIC_MBOX_MSG_RESET_XCAST 0xF2 /* Reset DCAM filtering mode */
+#define NIC_MBOX_MSG_ADD_MCAST 0xF3 /* Add MAC to DCAM filters */
+#define NIC_MBOX_MSG_SET_XCAST 0xF4 /* Set MCAST/BCAST RX mode */
struct nic_cfg_msg {
u8 msg;
@@ -556,6 +559,14 @@ struct set_ptp {
bool enable;
};
+struct xcast {
+ u8 msg;
+ union {
+ u8 mode;
+ u64 mac;
+ } data;
+};
+
/* 128 bit shared memory between PF and each VF */
union nic_mbx {
struct { u8 msg; } msg;
@@ -576,6 +587,7 @@ union nic_mbx {
struct reset_stat_cfg reset_stat;
struct pfc pfc;
struct set_ptp ptp;
+ struct xcast xcast;
};
#define NIC_NODE_ID_MASK 0x03
--
2.14.3
^ permalink raw reply related
* [PATCH v2 5/7] net: thunderx: add XCAST messages handlers for PF
From: Vadim Lomovtsev @ 2018-03-30 11:59 UTC (permalink / raw)
To: sgoutham, sunil.kovvuri, rric, linux-arm-kernel, netdev,
linux-kernel, davem
Cc: dnelson, ynorov, Vadim Lomovtsev
In-Reply-To: <20180330115953.17154-1-Vadim.Lomovtsev@caviumnetworks.com>
From: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
This commit is to add message handling for ndo_set_rx_mode()
callback at PF side.
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nic_main.c | 45 +++++++++++++++++++++++---
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 7ff66a8194e2..55af04fa03a7 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -21,6 +21,8 @@
#define DRV_NAME "nicpf"
#define DRV_VERSION "1.0"
+#define NIC_VF_PER_MBX_REG 64
+
struct hw_info {
u8 bgx_cnt;
u8 chans_per_lmac;
@@ -1072,6 +1074,40 @@ static void nic_handle_mbx_intr(struct nicpf *nic, int vf)
case NIC_MBOX_MSG_PTP_CFG:
nic_config_timestamp(nic, vf, &mbx.ptp);
break;
+ case NIC_MBOX_MSG_RESET_XCAST:
+ if (vf >= nic->num_vf_en) {
+ ret = -1; /* NACK */
+ break;
+ }
+ bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+ lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+ bgx_reset_xcast_mode(nic->node, bgx, lmac,
+ vf < NIC_VF_PER_MBX_REG ? vf :
+ vf - NIC_VF_PER_MBX_REG);
+ break;
+
+ case NIC_MBOX_MSG_ADD_MCAST:
+ if (vf >= nic->num_vf_en) {
+ ret = -1; /* NACK */
+ break;
+ }
+ bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+ lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+ bgx_set_dmac_cam_filter(nic->node, bgx, lmac,
+ mbx.xcast.data.mac,
+ vf < NIC_VF_PER_MBX_REG ? vf :
+ vf - NIC_VF_PER_MBX_REG);
+ break;
+
+ case NIC_MBOX_MSG_SET_XCAST:
+ if (vf >= nic->num_vf_en) {
+ ret = -1; /* NACK */
+ break;
+ }
+ bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+ lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+ bgx_set_xcast_mode(nic->node, bgx, lmac, mbx.xcast.data.mode);
+ break;
default:
dev_err(&nic->pdev->dev,
"Invalid msg from VF%d, msg 0x%x\n", vf, mbx.msg.msg);
@@ -1094,7 +1130,7 @@ static irqreturn_t nic_mbx_intr_handler(int irq, void *nic_irq)
struct nicpf *nic = (struct nicpf *)nic_irq;
int mbx;
u64 intr;
- u8 vf, vf_per_mbx_reg = 64;
+ u8 vf;
if (irq == pci_irq_vector(nic->pdev, NIC_PF_INTR_ID_MBOX0))
mbx = 0;
@@ -1103,12 +1139,13 @@ static irqreturn_t nic_mbx_intr_handler(int irq, void *nic_irq)
intr = nic_reg_read(nic, NIC_PF_MAILBOX_INT + (mbx << 3));
dev_dbg(&nic->pdev->dev, "PF interrupt Mbox%d 0x%llx\n", mbx, intr);
- for (vf = 0; vf < vf_per_mbx_reg; vf++) {
+ for (vf = 0; vf < NIC_VF_PER_MBX_REG; vf++) {
if (intr & (1ULL << vf)) {
dev_dbg(&nic->pdev->dev, "Intr from VF %d\n",
- vf + (mbx * vf_per_mbx_reg));
+ vf + (mbx * NIC_VF_PER_MBX_REG));
- nic_handle_mbx_intr(nic, vf + (mbx * vf_per_mbx_reg));
+ nic_handle_mbx_intr(nic, vf +
+ (mbx * NIC_VF_PER_MBX_REG));
nic_clear_mbx_intr(nic, vf, mbx);
}
}
--
2.14.3
^ permalink raw reply related
* [PATCH v2 6/7] net: thunderx: add workqueue control structures for handle ndo_set_rx_mode request
From: Vadim Lomovtsev @ 2018-03-30 11:59 UTC (permalink / raw)
To: sgoutham, sunil.kovvuri, rric, linux-arm-kernel, netdev,
linux-kernel, davem
Cc: dnelson, ynorov, Vadim Lomovtsev
In-Reply-To: <20180330115953.17154-1-Vadim.Lomovtsev@caviumnetworks.com>
From: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
The kernel calls ndo_set_rx_mode() callback from atomic context which
causes messaging timeouts between VF and PF (as they’re implemented via
MSIx). So in order to handle ndo_set_rx_mode() we need to get rid of it.
This commit implements necessary workqueue related structures to let VF
queue kernel request processing in non-atomic context later.
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nic.h | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/ethernet/cavium/thunder/nic.h b/drivers/net/ethernet/cavium/thunder/nic.h
index 069289b4f968..5fc46c5a4f36 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -265,6 +265,22 @@ struct nicvf_drv_stats {
struct cavium_ptp;
+struct xcast_addr {
+ struct list_head list;
+ u64 addr;
+};
+
+struct xcast_addr_list {
+ struct list_head list;
+ int count;
+};
+
+struct nicvf_work {
+ struct delayed_work work;
+ u8 mode;
+ struct xcast_addr_list *mc;
+};
+
struct nicvf {
struct nicvf *pnicvf;
struct net_device *netdev;
@@ -313,6 +329,7 @@ struct nicvf {
struct nicvf_pfc pfc;
struct tasklet_struct qs_err_task;
struct work_struct reset_task;
+ struct nicvf_work rx_mode_work;
/* PTP timestamp */
struct cavium_ptp *ptp_clock;
--
2.14.3
^ permalink raw reply related
* [PATCH v2 7/7] net: thunderx: add ndo_set_rx_mode callback implementation for VF
From: Vadim Lomovtsev @ 2018-03-30 11:59 UTC (permalink / raw)
To: sgoutham, sunil.kovvuri, rric, linux-arm-kernel, netdev,
linux-kernel, davem
Cc: dnelson, ynorov, Vadim Lomovtsev
In-Reply-To: <20180330115953.17154-1-Vadim.Lomovtsev@caviumnetworks.com>
From: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
The ndo_set_rx_mode() is called from atomic context which causes
messages response timeouts while VF to PF communication via MSIx.
To get rid of that we're copy passed mc list, parse flags and queue
handling of kernel request to ordered workqueue.
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@cavium.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 110 ++++++++++++++++++++++-
1 file changed, 109 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 7d9c5ffbd041..c8a8faaf17e9 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -21,6 +21,7 @@
#include <linux/bpf_trace.h>
#include <linux/filter.h>
#include <linux/net_tstamp.h>
+#include <linux/workqueue.h>
#include "nic_reg.h"
#include "nic.h"
@@ -67,6 +68,9 @@ module_param(cpi_alg, int, S_IRUGO);
MODULE_PARM_DESC(cpi_alg,
"PFC algorithm (0=none, 1=VLAN, 2=VLAN16, 3=IP Diffserv)");
+/* workqueue for handling kernel ndo_set_rx_mode() calls */
+static struct workqueue_struct *nicvf_rx_mode_wq;
+
static inline u8 nicvf_netdev_qidx(struct nicvf *nic, u8 qidx)
{
if (nic->sqs_mode)
@@ -1919,6 +1923,100 @@ static int nicvf_ioctl(struct net_device *netdev, struct ifreq *req, int cmd)
}
}
+static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
+{
+ struct nicvf_work *vf_work = container_of(work_arg, struct nicvf_work,
+ work.work);
+ struct nicvf *nic = container_of(vf_work, struct nicvf, rx_mode_work);
+ union nic_mbx mbx = {};
+ struct xcast_addr *xaddr, *next;
+
+ if (!vf_work)
+ return;
+
+ /* From the inside of VM code flow we have only 128 bits memory
+ * available to send message to host's PF, so send all mc addrs
+ * one by one, starting from flush command in case if kernel
+ * requests to configure specific MAC filtering
+ */
+
+ /* flush DMAC filters and reset RX mode */
+ mbx.xcast.msg = NIC_MBOX_MSG_RESET_XCAST;
+ nicvf_send_msg_to_pf(nic, &mbx);
+
+ if (vf_work->mode & BGX_XCAST_MCAST_FILTER) {
+ /* once enabling filtering, we need to signal to PF to add
+ * its' own LMAC to the filter to accept packets for it.
+ */
+ mbx.xcast.msg = NIC_MBOX_MSG_ADD_MCAST;
+ mbx.xcast.data.mac = 0;
+ nicvf_send_msg_to_pf(nic, &mbx);
+ }
+
+ /* check if we have any specific MACs to be added to PF DMAC filter */
+ if (vf_work->mc) {
+ /* now go through kernel list of MACs and add them one by one */
+ list_for_each_entry_safe(xaddr, next,
+ &vf_work->mc->list, list) {
+ mbx.xcast.msg = NIC_MBOX_MSG_ADD_MCAST;
+ mbx.xcast.data.mac = xaddr->addr;
+ nicvf_send_msg_to_pf(nic, &mbx);
+
+ /* after receiving ACK from PF release memory */
+ list_del(&xaddr->list);
+ kfree(xaddr);
+ vf_work->mc->count--;
+ }
+ kfree(vf_work->mc);
+ }
+
+ /* and finally set rx mode for PF accordingly */
+ mbx.xcast.msg = NIC_MBOX_MSG_SET_XCAST;
+ mbx.xcast.data.mode = vf_work->mode;
+
+ nicvf_send_msg_to_pf(nic, &mbx);
+}
+
+static void nicvf_set_rx_mode(struct net_device *netdev)
+{
+ struct nicvf *nic = netdev_priv(netdev);
+ struct netdev_hw_addr *ha;
+ struct xcast_addr_list *mc_list = NULL;
+ u8 mode = 0;
+
+ if (netdev->flags & IFF_PROMISC) {
+ mode = BGX_XCAST_BCAST_ACCEPT | BGX_XCAST_MCAST_ACCEPT;
+ } else {
+ if (netdev->flags & IFF_BROADCAST)
+ mode |= BGX_XCAST_BCAST_ACCEPT;
+
+ if (netdev->flags & IFF_ALLMULTI) {
+ mode |= BGX_XCAST_MCAST_ACCEPT;
+ } else if (netdev->flags & IFF_MULTICAST) {
+ mode |= BGX_XCAST_MCAST_FILTER;
+ /* here we need to copy mc addrs */
+ if (netdev_mc_count(netdev)) {
+ struct xcast_addr *xaddr;
+
+ mc_list = kmalloc(sizeof(*mc_list), GFP_ATOMIC);
+ INIT_LIST_HEAD(&mc_list->list);
+ netdev_hw_addr_list_for_each(ha, &netdev->mc) {
+ xaddr = kmalloc(sizeof(*xaddr),
+ GFP_ATOMIC);
+ xaddr->addr =
+ ether_addr_to_u64(ha->addr);
+ list_add_tail(&xaddr->list,
+ &mc_list->list);
+ mc_list->count++;
+ }
+ }
+ }
+ }
+ nic->rx_mode_work.mc = mc_list;
+ nic->rx_mode_work.mode = mode;
+ queue_delayed_work(nicvf_rx_mode_wq, &nic->rx_mode_work.work, 2 * HZ);
+}
+
static const struct net_device_ops nicvf_netdev_ops = {
.ndo_open = nicvf_open,
.ndo_stop = nicvf_stop,
@@ -1931,6 +2029,7 @@ static const struct net_device_ops nicvf_netdev_ops = {
.ndo_set_features = nicvf_set_features,
.ndo_bpf = nicvf_xdp,
.ndo_do_ioctl = nicvf_ioctl,
+ .ndo_set_rx_mode = nicvf_set_rx_mode,
};
static int nicvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
@@ -2071,6 +2170,8 @@ static int nicvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
INIT_WORK(&nic->reset_task, nicvf_reset_task);
+ INIT_DELAYED_WORK(&nic->rx_mode_work.work, nicvf_set_rx_mode_task);
+
err = register_netdev(netdev);
if (err) {
dev_err(dev, "Failed to register netdevice\n");
@@ -2109,6 +2210,8 @@ static void nicvf_remove(struct pci_dev *pdev)
nic = netdev_priv(netdev);
pnetdev = nic->pnicvf->netdev;
+ cancel_delayed_work_sync(&nic->rx_mode_work.work);
+
/* Check if this Qset is assigned to different VF.
* If yes, clean primary and all secondary Qsets.
*/
@@ -2140,12 +2243,17 @@ static struct pci_driver nicvf_driver = {
static int __init nicvf_init_module(void)
{
pr_info("%s, ver %s\n", DRV_NAME, DRV_VERSION);
-
+ nicvf_rx_mode_wq = alloc_ordered_workqueue("nicvf_generic",
+ WQ_MEM_RECLAIM);
return pci_register_driver(&nicvf_driver);
}
static void __exit nicvf_cleanup_module(void)
{
+ if (nicvf_rx_mode_wq) {
+ destroy_workqueue(nicvf_rx_mode_wq);
+ nicvf_rx_mode_wq = NULL;
+ }
pci_unregister_driver(&nicvf_driver);
}
--
2.14.3
^ permalink raw reply related
* Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support
From: Alexandre Belloni @ 2018-03-30 12:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: David S . Miller, Allan Nielsen, razvan.stefanescu, po.liu,
Thomas Petazzoni, Andrew Lunn, netdev, devicetree, linux-kernel,
linux-mips
In-Reply-To: <1df0a932-f7c1-f1b5-9a35-3c16d0c551e5@gmail.com>
On 23/03/2018 at 14:41:25 -0700, Florian Fainelli wrote:
> On 03/23/2018 01:11 PM, Alexandre Belloni wrote:
> > Add a driver for Microsemi Ocelot Ethernet switch support.
> >
> > This makes two modules:
> > mscc_ocelot_common handles all the common features that doesn't depend on
> > how the switch is integrated in the SoC. Currently, it handles offloading
> > bridging to the hardware. ocelot_io.c handles register accesses. This is
> > unfortunately needed because the register layout is packed and then depends
> > on the number of ports available on the switch. The register definition
> > files are automatically generated.
> >
> > ocelot_board handles the switch integration on the SoC and on the board.
> >
> > Frame injection and extraction to/from the CPU port is currently done using
> > register accesses which is quite slow. DMA is possible but the port is not
> > able to absorb the whole switch bandwidth.
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>
> Random drive by comments because this is quite a number of lines to review!
>
> Overall, looks quite good for a first version. Out of curiosity, is
> there a particular switch test you ran this driver against? LNST?
>
We have a really small custom test suite.
> > + /* Add dummy CRC */
> > + ocelot_write_rix(ocelot, 0, QS_INJ_WR, grp);
> > + skb_tx_timestamp(skb);
> > +
> > + dev->stats.tx_packets++;
> > + dev->stats.tx_bytes += skb->len;
> > + dev_kfree_skb_any(skb);
>
> No interrupt to indicate transmit completion?
>
No, unfortunately, the TX interrupts only indicates there is room to
start injecting frames, not that they have been transmitted.
>
> > +static int ocelot_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
> > + struct net_device *dev, const unsigned char *addr,
> > + u16 vid, u16 flags)
> > +{
> > + struct ocelot_port *port = netdev_priv(dev);
> > + struct ocelot *ocelot = port->ocelot;
> > +
> > + if (!vid) {
> > + if (!port->vlan_aware)
> > + /* If the bridge is not VLAN aware and no VID was
> > + * provided, set it to 1 as bridges have a default VID
> > + * of 1. Otherwise the MAC entry wouldn't match incoming
> > + * packets as the VID would differ (0 != 1).
> > + */
> > + vid = 1;
> > + else
> > + /* If the bridge is VLAN aware a VID must be provided as
> > + * otherwise the learnt entry wouldn't match any frame.
> > + */
> > + return -EINVAL;
> > + }
>
> So if we are targeting vid = 0 we end-up with vid = 1 possibly?
>
I've removed that part that is not needed for now and will rework when
sending VLAN support.
> > + ocelot_write_gix(ocelot, port_cfg, ANA_PORT_PORT_CFG,
> > + ocelot_port->chip_port);
> > +
> > + /* Apply FWD mask. The loop is needed to add/remove the current port as
> > + * a source for the other ports.
> > + */
> > + for (port = 0; port < ocelot->num_phys_ports; port++) {
> > + if (ocelot->bridge_fwd_mask & BIT(port)) {
> > + unsigned long mask = ocelot->bridge_fwd_mask & ~BIT(port);
> > +
> > + for (i = 0; i < ocelot->num_phys_ports; i++) {
> > + unsigned long bond_mask = ocelot->lags[i];
> > +
> > + if (!bond_mask)
> > + continue;
> > +
> > + if (bond_mask & BIT(port)) {
> > + mask &= ~bond_mask;
> > + break;
> > + }
> > + }
> > +
> > + ocelot_write_rix(ocelot,
> > + BIT(ocelot->num_phys_ports) | mask,
> > + ANA_PGID_PGID, PGID_SRC + port);
> > + } else {
> > + /* Only the CPU port, this is compatible with link
> > + * aggregation.
> > + */
> > + ocelot_write_rix(ocelot,
> > + BIT(ocelot->num_phys_ports),
> > + ANA_PGID_PGID, PGID_SRC + port);
> > + }
>
> All of this sounds like it should be moved into the br_join/leave, this
> does not appear to be the right place to do that.
>
No, I've triple checked because this is a comment that both Andrew and
you had. Once a port is added to the PGID MASK, it will start forwarding
frames so we really want that to happen only when the port is in
BR_STATE_FORWARDING state. Else, we may forward frames between the
addition of the port to the bridge and setting the port to the
BR_STATE_BLOCKING state.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* r8152 livelocks during pm_runtime_suspend
From: Jiri Slaby @ 2018-03-30 13:17 UTC (permalink / raw)
To: hayeswang; +Cc: USB list, ML netdev, Rafael J. Wysocki, Linux PM list
Hi,
I have seen r8152 from my docking station to kill my box several times
in the last few days. The notebook is new, so I don't know if this is a
regression.
I have the NIC connected all the time. And when I return to the notebook
after a while, the networking is dead. Looking at the stack traces, it
is clear, that r8152 was attempted to be autosuspended and waits in
napi_disable for NAPI_STATE_SCHED bit to be cleared:
[22001.018437] kworker/2:0 D 0 16267 2 0x80000000
[22001.018441] Workqueue: pm pm_runtime_work
[22001.018443] Call Trace:
[22001.018453] schedule+0x2f/0x90
[22001.018455] schedule_timeout+0x1ce/0x540
[22001.018474] msleep+0x29/0x30
[22001.018477] napi_disable+0x25/0x60
[22001.018483] rtl8152_suspend+0x20a/0x2d0 [r8152]
[22001.018493] usb_suspend_both+0x8d/0x200 [usbcore]
[22001.018510] usb_runtime_suspend+0x2a/0x70 [usbcore]
[22001.018514] __rpm_callback+0xbc/0x1f0
[22001.018519] rpm_callback+0x4f/0x70
[22001.018526] rpm_suspend+0x11d/0x6d0
[22001.018532] pm_runtime_work+0x73/0xb0
[22001.018535] process_one_work+0x269/0x6c0
[22001.018541] worker_thread+0x2b/0x3d0
[22001.018547] kthread+0x113/0x130
[22001.018556] ret_from_fork+0x24/0x50
The assembly:
> ffffffff81716730 <napi_disable>:
> ffffffff81716730: e8 eb b7 2e 00 callq ffffffff81a01f20 <__fentry__>
> ffffffff81716735: 55 push %rbp
> ffffffff81716736: 48 89 fd mov %rdi,%rbp
> ffffffff81716739: 53 push %rbx
> ffffffff8171673a: 48 8d 5f 10 lea 0x10(%rdi),%rbx
> ffffffff8171673e: f0 80 4f 10 04 lock orb $0x4,0x10(%rdi)
> ffffffff81716743: f0 0f ba 6f 10 00 lock btsl $0x0,0x10(%rdi)
> ffffffff81716749: 73 11 jae ffffffff8171675c <napi_disable+0x2c>
> ffffffff8171674b: bf 01 00 00 00 mov $0x1,%edi
> ffffffff81716750: e8 ab ac a0 ff callq ffffffff81121400 <msleep>
> ffffffff81716755: f0 0f ba 2b 00 lock btsl $0x0,(%rbx)
> ffffffff8171675a: 72 ef jb ffffffff8171674b <napi_disable+0x1b>
There are other tasks in D state, of course, like these, waiting for the
device to become pm-up:
[22001.018749] kworker/3:1 D 0 16798 2 0x80000000
[22001.018753] Workqueue: events rtl_work_func_t [r8152]
[22001.018755] Call Trace:
[22001.018767] schedule+0x2f/0x90
[22001.018769] rpm_resume+0xf9/0x860
[22001.018777] rpm_resume+0x592/0x860
[22001.018783] __pm_runtime_resume+0x3a/0x50
[22001.018789] usb_autopm_get_interface+0x1d/0x50 [usbcore]
[22001.018793] rtl_work_func_t+0x3e/0x405 [r8152]
[22001.018801] process_one_work+0x269/0x6c0
[22001.018807] worker_thread+0x2b/0x3d0
[22001.018813] kthread+0x113/0x130
[22001.018822] ret_from_fork+0x24/0x50
[22001.019713] tcpdump D 0 17119 4265 0x00000004
[22001.019716] Call Trace:
[22001.019728] schedule+0x2f/0x90
[22001.019730] rpm_resume+0xf9/0x860
[22001.019738] rpm_resume+0x592/0x860
[22001.019744] __pm_runtime_resume+0x3a/0x50
[22001.019750] usb_autopm_get_interface+0x1d/0x50 [usbcore]
[22001.019754] rtl8152_ioctl+0x30/0x140 [r8152]
[22001.019758] dev_ifsioc+0x115/0x3f0
[22001.019763] dev_ioctl+0x14b/0x680
[22001.019775] sock_do_ioctl+0x41/0x50
[22001.019778] sock_ioctl+0x1c2/0x2f0
[22001.019781] do_vfs_ioctl+0x91/0x680
[22001.019789] SyS_ioctl+0x74/0x80
[22001.019794] do_syscall_64+0x76/0x1c0
...
> Showing all locks held in the system:
> 1 lock held by in:imklog/1371:
> #0: (&f->f_pos_lock){+.+.}, at: [<00000000a0b38807>] __fdget_pos+0x3f/0x50
> 1 lock held by Qt bearer threa/3003:
> #0: (rtnl_mutex){+.+.}, at: [<0000000021e0bca0>] __netlink_dump_start+0x4c/0x1b0
> 1 lock held by Qt bearer threa/2825:
> #0: (rtnl_mutex){+.+.}, at: [<0000000021e0bca0>] __netlink_dump_start+0x4c/0x1b0
> 1 lock held by DNS Res~ver #40/17041:
> #0: (rtnl_mutex){+.+.}, at: [<0000000021e0bca0>] __netlink_dump_start+0x4c/0x1b0
> 1 lock held by Qt bearer threa/3110:
> #0: (rtnl_mutex){+.+.}, at: [<0000000021e0bca0>] __netlink_dump_start+0x4c/0x1b0
> 1 lock held by DNS Res~ver #16/17044:
> #0: (rtnl_mutex){+.+.}, at: [<0000000021e0bca0>] __netlink_dump_start+0x4c/0x1b0
> 2 locks held by bash/4561:
> #0: (&tty->ldisc_sem){++++}, at: [<00000000e3d76e61>] tty_ldisc_ref_wait+0x24/0x50
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<0000000091462d05>] n_tty_read+0xc3/0x850
> 3 locks held by kworker/2:0/16267:
> #0: ((wq_completion)"pm"){+.+.}, at: [<00000000b9dc0832>] process_one_work+0x1e3/0x6c0
> #1: ((work_completion)(&dev->power.work)){+.+.}, at: [<00000000b9dc0832>] process_one_work+0x1e3/0x6c0
> #2: (&tp->control){+.+.}, at: [<00000000ca575b90>] rtl8152_suspend+0x2b/0x2d0 [r8152]
> 2 locks held by kworker/3:1/16798:
> #0: ((wq_completion)"events"){+.+.}, at: [<00000000b9dc0832>] process_one_work+0x1e3/0x6c0
> #1: ((work_completion)(&(&tp->schedule)->work)){+.+.}, at: [<00000000b9dc0832>] process_one_work+0x1e3/0x6c0
> 1 lock held by tcpdump/17119:
> #0: (rtnl_mutex){+.+.}, at: [<0000000023a6461d>] dev_ioctl+0x13d/0x680
> 2 locks held by less/17187:
> #0: (&tty->ldisc_sem){++++}, at: [<00000000e3d76e61>] tty_ldisc_ref_wait+0x24/0x50
> #1: (&ldata->atomic_read_lock){+.+.}, at: [<0000000091462d05>] n_tty_read+0xc3/0x850
For now, I disabled pm-runtime on the device by:
echo on > /sys/bus/usb/devices/4-1.2/power/control
Any ideas what's wrong? napi_disable from runtime suspend? Double
napi_disable on the path? Some missing pm_runtime_get_sync somewhere?
Full dmesg after sysrq-t:
https://www.fi.muni.cz/~xslaby/sklad/panics/r8152.txt
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH net-next 4/6] inet: frags: use rhashtables for reassembly units
From: Eric Dumazet @ 2018-03-30 13:30 UTC (permalink / raw)
To: Herbert Xu, Eric Dumazet
Cc: David S . Miller, netdev, Florian Westphal, Thomas Graf,
Jesper Dangaard Brouer, Alexander Aring, Stefan Schmidt,
Eric Dumazet, Nikolay Aleksandrov
In-Reply-To: <20180330071814.GA27025@gondor.apana.org.au>
On 03/30/2018 12:18 AM, Herbert Xu wrote:
> Instead of using the walk interface, how about
> rhashtable_free_and_destroy?
Oh, I was not aware of this beast ;)
I guess I will need to add a cond_resched() in it, right ?
My rough guess is that freeing 30 million frags would take few seconds ;)
>
>> void inet_frag_kill(struct inet_frag_queue *fq)
>> {
>> if (del_timer(&fq->timer))
>> refcount_dec(&fq->refcnt);
>>
>> if (!(fq->flags & INET_FRAG_COMPLETE)) {
>> - fq_unlink(fq);
>> + struct netns_frags *nf = fq->net;
>> +
>> + fq->flags |= INET_FRAG_COMPLETE;
>> + rhashtable_remove_fast(&nf->rhashtable, &fq->node, nf->f->rhash_params);
>> refcount_dec(&fq->refcnt);
>> }
>> }
>
> This means that the hash won't inline properly. Don't know big
> of an issue it is to you. But you could fix it by doing the same
> hack as rhashtable by making inet_frag_kill an inline function and
> take the rhash_params as an explicit argument.
I will investigate this, thanks !
^ permalink raw reply
* Re: r8152 livelocks during pm_runtime_suspend
From: Jiri Slaby @ 2018-03-30 13:37 UTC (permalink / raw)
To: hayeswang; +Cc: USB list, ML netdev, Rafael J. Wysocki, Linux PM list
In-Reply-To: <d1e1a702-753f-ec83-ed71-7e3649b20757@suse.cz>
On 03/30/2018, 03:17 PM, Jiri Slaby wrote:
> Hi,
>
> I have seen r8152 from my docking station to kill my box several times
> in the last few days. The notebook is new, so I don't know if this is a
> regression.
Forgot to add, I am seeing this in dmesg:
[ 13.353239] r8152 4-1.2:1.0 (unnamed net_device) (uninitialized):
Using pass-thru MAC addr d8:9e:f3:f6:6d:0c
[ 13.365082] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 13.390990] r8152 4-1.2:1.0 eth1: v1.09.9
[ 13.399314] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 13.552529] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 13.561268] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 13.736582] nf_conntrack version 0.5.0 (65536 buckets, 262144 max)
[ 14.198646] bridge: filtering via arp/ip/ip6tables is no longer
available by default. Update your scripts to load br_netfilter if you
need this.
[ 14.537233] Netfilter messages via NETLINK v0.30.
[ 14.544740] ip_set: protocol 6
[ 16.697657] r8152 4-1.2:1.0 eth1: carrier on
[ 16.697724] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 16.847718] NET: Registered protocol family 17
[ 20.629344] fuse init (API version 7.26)
[ 21.371334] Bluetooth: RFCOMM TTY layer initialized
[ 21.371343] Bluetooth: RFCOMM socket layer initialized
[ 21.371353] Bluetooth: RFCOMM ver 1.11
[ 21.753577] tun: Universal TUN/TAP device driver, 1.6
[ 25.992820] retire_capture_urb: 2491 callbacks suppressed
[ 118.054869] NOHZ: local_softirq_pending 08
[ 118.056988] NOHZ: local_softirq_pending 08
[ 185.562659] NOHZ: local_softirq_pending 08
08 seems to be NET_RX_SOFTIRQ. So is this related?
Kernel version: 4.15.14
> I have the NIC connected all the time. And when I return to the notebook
> after a while, the networking is dead. Looking at the stack traces, it
> is clear, that r8152 was attempted to be autosuspended and waits in
> napi_disable for NAPI_STATE_SCHED bit to be cleared:
> [22001.018437] kworker/2:0 D 0 16267 2 0x80000000
> [22001.018441] Workqueue: pm pm_runtime_work
> [22001.018443] Call Trace:
> [22001.018453] schedule+0x2f/0x90
> [22001.018455] schedule_timeout+0x1ce/0x540
> [22001.018474] msleep+0x29/0x30
> [22001.018477] napi_disable+0x25/0x60
> [22001.018483] rtl8152_suspend+0x20a/0x2d0 [r8152]
> [22001.018493] usb_suspend_both+0x8d/0x200 [usbcore]
> [22001.018510] usb_runtime_suspend+0x2a/0x70 [usbcore]
> [22001.018514] __rpm_callback+0xbc/0x1f0
> [22001.018519] rpm_callback+0x4f/0x70
> [22001.018526] rpm_suspend+0x11d/0x6d0
> [22001.018532] pm_runtime_work+0x73/0xb0
> [22001.018535] process_one_work+0x269/0x6c0
> [22001.018541] worker_thread+0x2b/0x3d0
> [22001.018547] kthread+0x113/0x130
> [22001.018556] ret_from_fork+0x24/0x50
>
> The assembly:
>> ffffffff81716730 <napi_disable>:
>> ffffffff81716730: e8 eb b7 2e 00 callq ffffffff81a01f20 <__fentry__>
>> ffffffff81716735: 55 push %rbp
>> ffffffff81716736: 48 89 fd mov %rdi,%rbp
>> ffffffff81716739: 53 push %rbx
>> ffffffff8171673a: 48 8d 5f 10 lea 0x10(%rdi),%rbx
>> ffffffff8171673e: f0 80 4f 10 04 lock orb $0x4,0x10(%rdi)
>> ffffffff81716743: f0 0f ba 6f 10 00 lock btsl $0x0,0x10(%rdi)
>> ffffffff81716749: 73 11 jae ffffffff8171675c <napi_disable+0x2c>
>> ffffffff8171674b: bf 01 00 00 00 mov $0x1,%edi
>> ffffffff81716750: e8 ab ac a0 ff callq ffffffff81121400 <msleep>
>> ffffffff81716755: f0 0f ba 2b 00 lock btsl $0x0,(%rbx)
>> ffffffff8171675a: 72 ef jb ffffffff8171674b <napi_disable+0x1b>
>
>
>
>
>
> There are other tasks in D state, of course, like these, waiting for the
> device to become pm-up:
> [22001.018749] kworker/3:1 D 0 16798 2 0x80000000
> [22001.018753] Workqueue: events rtl_work_func_t [r8152]
> [22001.018755] Call Trace:
> [22001.018767] schedule+0x2f/0x90
> [22001.018769] rpm_resume+0xf9/0x860
> [22001.018777] rpm_resume+0x592/0x860
> [22001.018783] __pm_runtime_resume+0x3a/0x50
> [22001.018789] usb_autopm_get_interface+0x1d/0x50 [usbcore]
> [22001.018793] rtl_work_func_t+0x3e/0x405 [r8152]
> [22001.018801] process_one_work+0x269/0x6c0
> [22001.018807] worker_thread+0x2b/0x3d0
> [22001.018813] kthread+0x113/0x130
> [22001.018822] ret_from_fork+0x24/0x50
> [22001.019713] tcpdump D 0 17119 4265 0x00000004
> [22001.019716] Call Trace:
> [22001.019728] schedule+0x2f/0x90
> [22001.019730] rpm_resume+0xf9/0x860
> [22001.019738] rpm_resume+0x592/0x860
> [22001.019744] __pm_runtime_resume+0x3a/0x50
> [22001.019750] usb_autopm_get_interface+0x1d/0x50 [usbcore]
> [22001.019754] rtl8152_ioctl+0x30/0x140 [r8152]
> [22001.019758] dev_ifsioc+0x115/0x3f0
> [22001.019763] dev_ioctl+0x14b/0x680
> [22001.019775] sock_do_ioctl+0x41/0x50
> [22001.019778] sock_ioctl+0x1c2/0x2f0
> [22001.019781] do_vfs_ioctl+0x91/0x680
> [22001.019789] SyS_ioctl+0x74/0x80
> [22001.019794] do_syscall_64+0x76/0x1c0
>
> ...
>
>> Showing all locks held in the system:
>> 1 lock held by in:imklog/1371:
>> #0: (&f->f_pos_lock){+.+.}, at: [<00000000a0b38807>] __fdget_pos+0x3f/0x50
>> 1 lock held by Qt bearer threa/3003:
>> #0: (rtnl_mutex){+.+.}, at: [<0000000021e0bca0>] __netlink_dump_start+0x4c/0x1b0
>> 1 lock held by Qt bearer threa/2825:
>> #0: (rtnl_mutex){+.+.}, at: [<0000000021e0bca0>] __netlink_dump_start+0x4c/0x1b0
>> 1 lock held by DNS Res~ver #40/17041:
>> #0: (rtnl_mutex){+.+.}, at: [<0000000021e0bca0>] __netlink_dump_start+0x4c/0x1b0
>> 1 lock held by Qt bearer threa/3110:
>> #0: (rtnl_mutex){+.+.}, at: [<0000000021e0bca0>] __netlink_dump_start+0x4c/0x1b0
>> 1 lock held by DNS Res~ver #16/17044:
>> #0: (rtnl_mutex){+.+.}, at: [<0000000021e0bca0>] __netlink_dump_start+0x4c/0x1b0
>> 2 locks held by bash/4561:
>> #0: (&tty->ldisc_sem){++++}, at: [<00000000e3d76e61>] tty_ldisc_ref_wait+0x24/0x50
>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<0000000091462d05>] n_tty_read+0xc3/0x850
>> 3 locks held by kworker/2:0/16267:
>> #0: ((wq_completion)"pm"){+.+.}, at: [<00000000b9dc0832>] process_one_work+0x1e3/0x6c0
>> #1: ((work_completion)(&dev->power.work)){+.+.}, at: [<00000000b9dc0832>] process_one_work+0x1e3/0x6c0
>> #2: (&tp->control){+.+.}, at: [<00000000ca575b90>] rtl8152_suspend+0x2b/0x2d0 [r8152]
>> 2 locks held by kworker/3:1/16798:
>> #0: ((wq_completion)"events"){+.+.}, at: [<00000000b9dc0832>] process_one_work+0x1e3/0x6c0
>> #1: ((work_completion)(&(&tp->schedule)->work)){+.+.}, at: [<00000000b9dc0832>] process_one_work+0x1e3/0x6c0
>> 1 lock held by tcpdump/17119:
>> #0: (rtnl_mutex){+.+.}, at: [<0000000023a6461d>] dev_ioctl+0x13d/0x680
>> 2 locks held by less/17187:
>> #0: (&tty->ldisc_sem){++++}, at: [<00000000e3d76e61>] tty_ldisc_ref_wait+0x24/0x50
>> #1: (&ldata->atomic_read_lock){+.+.}, at: [<0000000091462d05>] n_tty_read+0xc3/0x850
>
>
> For now, I disabled pm-runtime on the device by:
> echo on > /sys/bus/usb/devices/4-1.2/power/control
>
> Any ideas what's wrong? napi_disable from runtime suspend? Double
> napi_disable on the path? Some missing pm_runtime_get_sync somewhere?
>
> Full dmesg after sysrq-t:
> https://www.fi.muni.cz/~xslaby/sklad/panics/r8152.txt
>
> thanks,
>
--
js
suse labs
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: fix error return code in adap_init0()
From: David Miller @ 2018-03-30 13:52 UTC (permalink / raw)
To: weiyongjun1; +Cc: ganeshgr, kumaras, netdev, kernel-janitors
In-Reply-To: <1522241469-77623-1-git-send-email-weiyongjun1@huawei.com>
From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Wed, 28 Mar 2018 12:51:09 +0000
> Fix to return a negative error code from the hash filter init error
> handling case instead of 0, as done elsewhere in this function.
>
> Fixes: 5c31254e35a8 ("cxgb4: initialize hash-filter configuration")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Applied, thanks Wei.
^ permalink raw reply
* Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support
From: Andrew Lunn @ 2018-03-30 13:54 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Florian Fainelli, David S . Miller, Allan Nielsen,
razvan.stefanescu, po.liu, Thomas Petazzoni, netdev, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20180330124537.GC14180@piout.net>
> > All of this sounds like it should be moved into the br_join/leave, this
> > does not appear to be the right place to do that.
> >
>
> No, I've triple checked because this is a comment that both Andrew and
> you had. Once a port is added to the PGID MASK, it will start forwarding
> frames so we really want that to happen only when the port is in
> BR_STATE_FORWARDING state. Else, we may forward frames between the
> addition of the port to the bridge and setting the port to the
> BR_STATE_BLOCKING state.
Hi Alexandre
Interesting observation. I took a look at some of the other join
implementations. mv88e6xxx does the join immediately. mt7539 does it
immediately, if the port is enabled. lan9303 does it immediately.
qca8k does it immediately. b53 does it immediately.
Either they all get it wrong, or we make the assumption the bridge
sets the STP state first, then has the port join the bridge.
Looking at the code, br_add_if() it calls
netdev_master_upper_dev_link() and then later
if (netif_running(dev) && netif_oper_up(dev) &&
(br->dev->flags & IFF_UP))
br_stp_enable_port(p);
So it does look like there is a window of time between the port
joining and the STP state being set.
I know in the past, we have run into the opposite problem. A port
leaves the bridge, while in blocked state. The port should then
becomes an individual port, so the STP state needs setting to
forwarding. I don't remember where we fix this.
I don't like that this new driver is different, but it also looks like
we have a real problem here. More digging needed.
Andrew
^ permalink raw reply
* Re: [PATCH] tipc: avoid possible string overflow
From: David Miller @ 2018-03-30 13:54 UTC (permalink / raw)
To: arnd
Cc: jon.maloy, ying.xue, parthasarathy.bhuvaragan, netdev,
tipc-discussion, linux-kernel
In-Reply-To: <20180328140302.2594031-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 28 Mar 2018 16:02:04 +0200
> gcc points out that the combined length of the fixed-length inputs to
> l->name is larger than the destination buffer size:
>
> net/tipc/link.c: In function 'tipc_link_create':
> net/tipc/link.c:465:26: error: '%s' directive writing up to 32 bytes into a region of size between 26 and 58 [-Werror=format-overflow=]
> sprintf(l->name, "%s:%s-%s:unknown", self_str, if_name, peer_str);
> ^~ ~~~~~~~~
> net/tipc/link.c:465:2: note: 'sprintf' output 11 or more bytes (assuming 75) into a destination of size 60
> sprintf(l->name, "%s:%s-%s:unknown", self_str, if_name, peer_str);
>
> Using snprintf() ensures that the destination is still a nul-terminated
> string in all cases. It's still theoretically possible that the string
> gets trunctated though, so this patch should be carefully reviewed to
> ensure that either truncation is impossible in practice, or that we're
> ok with the truncation.
>
> Fixes: 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address hash values")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Based upon the discussion here, it looks like Jon will fix this in a different
way by increasing the destination buffer size.
^ permalink raw reply
* Re: [PATCH net-next] net: Call add/kill vid ndo on vlan filter feature toggling
From: David Miller @ 2018-03-30 13:59 UTC (permalink / raw)
To: galp; +Cc: netdev, tariqt
In-Reply-To: <1522248414-32539-1-git-send-email-galp@mellanox.com>
From: Gal Pressman <galp@mellanox.com>
Date: Wed, 28 Mar 2018 17:46:54 +0300
> NETIF_F_HW_VLAN_[CS]TAG_FILTER features require more than just a bit
> flip in dev->features in order to keep the driver in a consistent state.
> These features notify the driver of each added/removed vlan, but toggling
> of vlan-filter does not notify the driver accordingly for each of the
> existing vlans.
>
> This patch implements a similar solution to NETIF_F_RX_UDP_TUNNEL_PORT
> behavior (which notifies the driver about UDP ports in the same manner
> that vids are reported).
>
> Each toggling of the features propagates to the 8021q module, which
> iterates over the vlans and call add/kill ndo accordingly.
>
> Signed-off-by: Gal Pressman <galp@mellanox.com>
> Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Looks good, applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: Broadcom drivers coalescing fixes
From: David Miller @ 2018-03-30 14:04 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, jaedon.shin, pgynther, opendmb, michael.chan, gospo,
talgi, saeedm
In-Reply-To: <20180328221538.29290-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 28 Mar 2018 15:15:35 -0700
> Following Tal's review of the adaptive RX/TX coalescing feature added to the
> SYSTEMPORT and GENET driver a number of things showed up:
>
> - adaptive TX coalescing is not actually a good idea with the current way
> the estimator will program the ring, this results in a higher CPU load, NAPI
> on TX already does a reasonably good job at maintaining the interrupt count low
>
> - both SYSTEMPORT and GENET would suffer from the same issues while configuring
> coalescing parameters where the values would just not be applied correctly
> based on user settings, so we fix that too
>
> Tal, thanks again for your feedback, I would appreciate if you could review that
> the new behavior appears to be implemented correctly.
...
> Changes in v2:
>
> - added Tal's reviewed-by to the first patch
> - split DIM initialization from coalescing parameters initialization
> - avoid duplicating the same code in bcmgenet_set_coalesce() when configuring RX rings
> - fixed the condition where default DIM parameters would be applied when
> adaptive RX coalescing would be enabled, do this only if it was disabled before
Series applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH net-next] MAINTAINERS: update vmxnet3 driver maintainer
From: David Miller @ 2018-03-30 14:05 UTC (permalink / raw)
To: doshir
Cc: netdev, skhare, mchehab, gregkh, linus.walleij, akpm, rdunlap,
linux-kernel
In-Reply-To: <20180328223834.5452-1-doshir@vmware.com>
From: Ronak Doshi <doshir@vmware.com>
Date: Wed, 28 Mar 2018 15:38:19 -0700
> Shrikrishna Khare would no longer maintain the vmxnet3 driver. Taking
> over the role of vmxnet3 maintainer.
>
> Signed-off-by: Ronak Doshi <doshir@vmware.com>
> Signed-off-by: Shrikrishna Khare <skhare@vmware.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] phylink: API changes
From: David Miller @ 2018-03-30 14:11 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, thomas.petazzoni, andrew, rmk+kernel, linux-kernel,
antoine.tenart, ymarkman, stefanc, maxime.chevallier,
miquel.raynal, mw
In-Reply-To: <20180328224416.6981-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 28 Mar 2018 15:44:14 -0700
> This patch series contains two API changes to PHYLINK which will later be used
> by DSA to migrate to PHYLINK. Because these are API changes that impact other
> outstanding work (e.g: MVPP2) I would rather get them included sooner to minimize
> conflicts.
Series applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH] atm: iphase: fix spelling mistake: "Receiverd" -> "Received"
From: David Miller @ 2018-03-30 14:11 UTC (permalink / raw)
To: colin.king
Cc: 3chas3, linux-atm-general, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20180328231853.28461-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Thu, 29 Mar 2018 00:18:53 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in message text
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied, thanks Colin.
^ permalink raw reply
* Re: [PATCH] fix typo in command value in drivers/net/phy/mdio-bitbang.
From: Andrew Lunn @ 2018-03-30 14:14 UTC (permalink / raw)
To: Frans Meulenbroeks; +Cc: torvalds, linux-kernel, netdev
In-Reply-To: <CACW_hTauBL6but9143Kio-ZU5jsMKx2uTEUv3kHFaTGuwdyHZA@mail.gmail.com>
On Fri, Mar 30, 2018 at 02:03:38PM +0200, Frans Meulenbroeks wrote:
> mdio-bitbang mentioned 10 for both read and write.
> However mdio read opcode is 10 and write opcode is 01
> Fixed comment.
>
> Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com>
Hi Frans
The correct place to send this patch is <netdev@vger.kernel.org> and
David Miller <davem@davemloft.net>. Please can you submit it again, to
these addresses.
In general, if you don't know where to send a patch,
scripts/get_maintainers.pl will tell you.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
> ---
> drivers/net/phy/mdio-bitbang.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/mdio-bitbang.c b/drivers/net/phy/mdio-bitbang.c
> index 61a543c..403b085 100644
> --- a/drivers/net/phy/mdio-bitbang.c
> +++ b/drivers/net/phy/mdio-bitbang.c
> @@ -113,7 +113,7 @@ static void mdiobb_cmd(struct mdiobb_ctrl *ctrl, int
> op, u8 phy, u8 reg)
> for (i = 0; i < 32; i++)
> mdiobb_send_bit(ctrl, 1);
>
> - /* send the start bit (01) and the read opcode (10) or write (10).
> + /* send the start bit (01) and the read opcode (10) or write (01).
> Clause 45 operation uses 00 for the start and 11, 10 for
> read/write */
> mdiobb_send_bit(ctrl, 0);
> --
> 2.7.4
^ 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