* [RFC PATCH net-next 4/5] macvlan: basic XDP support
From: Jason Wang @ 2018-08-13 3:05 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: ast, daniel, jbrouer, mst, Jason Wang
In-Reply-To: <1534129513-4845-1-git-send-email-jasowang@redhat.com>
This patch tries to implementing basic XDP support for macvlan. The
implementation was split into two parts:
1) XDP rx handler of underlay device:
We will register an XDP rx handler (macvlan_handle_xdp) to under layer
device. In this handler, we will the following cases to go for slow
path (XDP_RX_HANDLER_PASS):
- The packet is a multicast packet.
- A vlan is source mode
- Destination mac address does not match any vlan
If none of the above cases were true, it means we could go for XDP
path directly. We will change the dev and return
RX_XDP_HANDLER_ANOTHER.
2) If we find a destination vlan, we will try to run XDP prog.
If XDP prog return XDP_PASS, we will call xdp_do_pass() to pass it to
up layer XDP rx handler. This is needed for e.g macvtap to work. If
XDP_RX_HANDLER_FALLBACK is returned, we will build skb and call
netif_rx() to finish the receiving. Otherwise just return the result
to lower device. For XDP_TX, we will build skb and try XDP generic
transmission routine for simplicity. This could be optimized on top.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvlan.c | 173 ++++++++++++++++++++++++++++++++++++++++++++-
include/linux/if_macvlan.h | 1 +
2 files changed, 171 insertions(+), 3 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index b7c814d..42b747c 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -34,6 +34,7 @@
#include <net/rtnetlink.h>
#include <net/xfrm.h>
#include <linux/netpoll.h>
+#include <linux/bpf.h>
#define MACVLAN_HASH_BITS 8
#define MACVLAN_HASH_SIZE (1<<MACVLAN_HASH_BITS)
@@ -436,6 +437,122 @@ static void macvlan_forward_source(struct sk_buff *skb,
}
}
+struct sk_buff *macvlan_xdp_build_skb(struct net_device *dev,
+ struct xdp_buff *xdp)
+{
+ int len;
+ int buflen = xdp->data_end - xdp->data_hard_start;
+ int headroom = xdp->data - xdp->data_hard_start;
+ struct sk_buff *skb;
+
+ len = SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) + headroom +
+ SKB_DATA_ALIGN(buflen);
+
+ skb = build_skb(xdp->data_hard_start, len);
+ if (!skb)
+ return NULL;
+
+ skb_reserve(skb, headroom);
+ __skb_put(skb, xdp->data_end - xdp->data);
+
+ skb->protocol = eth_type_trans(skb, dev);
+ skb->dev = dev;
+
+ return skb;
+}
+
+static rx_xdp_handler_result_t macvlan_receive_xdp(struct net_device *dev,
+ struct xdp_buff *xdp)
+{
+ struct macvlan_dev *vlan = netdev_priv(dev);
+ struct bpf_prog *xdp_prog;
+ struct sk_buff *skb;
+ u32 act = XDP_PASS;
+ rx_xdp_handler_result_t ret;
+ int err;
+
+ rcu_read_lock();
+ xdp_prog = rcu_dereference(vlan->xdp_prog);
+
+ if (xdp_prog)
+ act = bpf_prog_run_xdp(xdp_prog, xdp);
+
+ switch (act) {
+ case XDP_PASS:
+ ret = xdp_do_pass(xdp);
+ if (ret != RX_XDP_HANDLER_FALLBACK) {
+ rcu_read_unlock();
+ return ret;
+ }
+ skb = macvlan_xdp_build_skb(dev, xdp);
+ if (!skb) {
+ act = XDP_DROP;
+ break;
+ }
+ rcu_read_unlock();
+ netif_rx(skb);
+ macvlan_count_rx(vlan, skb->len, true, false);
+ goto out;
+ case XDP_TX:
+ skb = macvlan_xdp_build_skb(dev, xdp);
+ if (!skb) {
+ act = XDP_DROP;
+ break;
+ }
+ generic_xdp_tx(skb, xdp_prog);
+ break;
+ case XDP_REDIRECT:
+ err = xdp_do_redirect(dev, xdp, xdp_prog);
+ xdp_do_flush_map();
+ if (err)
+ act = XDP_DROP;
+ break;
+ case XDP_DROP:
+ break;
+ default:
+ bpf_warn_invalid_xdp_action(act);
+ break;
+ }
+
+ rcu_read_unlock();
+out:
+ if (act == XDP_DROP)
+ return RX_XDP_HANDLER_DROP;
+
+ return RX_XDP_HANDLER_CONSUMED;
+}
+
+/* called under rcu_read_lock() from XDP handler */
+static rx_xdp_handler_result_t macvlan_handle_xdp(struct net_device *dev,
+ struct xdp_buff *xdp)
+{
+ const struct ethhdr *eth = (const struct ethhdr *)xdp->data;
+ struct macvlan_port *port;
+ struct macvlan_dev *vlan;
+
+ if (is_multicast_ether_addr(eth->h_dest))
+ return RX_XDP_HANDLER_FALLBACK;
+
+ port = macvlan_port_get_rcu(dev);
+ if (port->source_count)
+ return RX_XDP_HANDLER_FALLBACK;
+
+ if (macvlan_passthru(port))
+ vlan = list_first_or_null_rcu(&port->vlans,
+ struct macvlan_dev, list);
+ else
+ vlan = macvlan_hash_lookup(port, eth->h_dest);
+
+ if (!vlan)
+ return RX_XDP_HANDLER_FALLBACK;
+
+ dev = vlan->dev;
+ if (unlikely(!(dev->flags & IFF_UP)))
+ return RX_XDP_HANDLER_DROP;
+
+ return macvlan_receive_xdp(dev, xdp);
+}
+
/* called under rcu_read_lock() from netif_receive_skb */
static rx_handler_result_t macvlan_handle_frame(struct sk_buff **pskb)
{
@@ -1089,6 +1206,44 @@ static int macvlan_dev_get_iflink(const struct net_device *dev)
return vlan->lowerdev->ifindex;
}
+static int macvlan_xdp_set(struct net_device *dev, struct bpf_prog *prog,
+ struct netlink_ext_ack *extack)
+{
+ struct macvlan_dev *vlan = netdev_priv(dev);
+ struct bpf_prog *old_prog = rtnl_dereference(vlan->xdp_prog);
+
+ rcu_assign_pointer(vlan->xdp_prog, prog);
+
+ if (old_prog)
+ bpf_prog_put(old_prog);
+
+ return 0;
+}
+
+static u32 macvlan_xdp_query(struct net_device *dev)
+{
+ struct macvlan_dev *vlan = netdev_priv(dev);
+ const struct bpf_prog *xdp_prog = rtnl_dereference(vlan->xdp_prog);
+
+ if (xdp_prog)
+ return xdp_prog->aux->id;
+
+ return 0;
+}
+
+static int macvlan_xdp(struct net_device *dev, struct netdev_bpf *xdp)
+{
+ switch (xdp->command) {
+ case XDP_SETUP_PROG:
+ return macvlan_xdp_set(dev, xdp->prog, xdp->extack);
+ case XDP_QUERY_PROG:
+ xdp->prog_id = macvlan_xdp_query(dev);
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
static const struct ethtool_ops macvlan_ethtool_ops = {
.get_link = ethtool_op_get_link,
.get_link_ksettings = macvlan_ethtool_get_link_ksettings,
@@ -1121,6 +1276,7 @@ static const struct net_device_ops macvlan_netdev_ops = {
#endif
.ndo_get_iflink = macvlan_dev_get_iflink,
.ndo_features_check = passthru_features_check,
+ .ndo_bpf = macvlan_xdp,
};
void macvlan_common_setup(struct net_device *dev)
@@ -1173,10 +1329,20 @@ static int macvlan_port_create(struct net_device *dev)
INIT_WORK(&port->bc_work, macvlan_process_broadcast);
err = netdev_rx_handler_register(dev, macvlan_handle_frame, port);
- if (err)
+ if (err) {
kfree(port);
- else
- dev->priv_flags |= IFF_MACVLAN_PORT;
+ goto out;
+ }
+
+ err = netdev_rx_xdp_handler_register(dev, macvlan_handle_xdp);
+ if (err) {
+ netdev_rx_handler_unregister(dev);
+ kfree(port);
+ goto out;
+ }
+
+ dev->priv_flags |= IFF_MACVLAN_PORT;
+out:
return err;
}
@@ -1187,6 +1353,7 @@ static void macvlan_port_destroy(struct net_device *dev)
dev->priv_flags &= ~IFF_MACVLAN_PORT;
netdev_rx_handler_unregister(dev);
+ netdev_rx_xdp_handler_unregister(dev);
/* After this point, no packet can schedule bc_work anymore,
* but we need to cancel it and purge left skbs if any.
diff --git a/include/linux/if_macvlan.h b/include/linux/if_macvlan.h
index 2e55e4c..7c7059b 100644
--- a/include/linux/if_macvlan.h
+++ b/include/linux/if_macvlan.h
@@ -34,6 +34,7 @@ struct macvlan_dev {
#ifdef CONFIG_NET_POLL_CONTROLLER
struct netpoll *netpoll;
#endif
+ struct bpf_prog __rcu *xdp_prog;
};
static inline void macvlan_count_rx(const struct macvlan_dev *vlan,
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] virtio_net: remove duplicated include from virtio_net.c
From: YueHaibing @ 2018-08-13 6:13 UTC (permalink / raw)
To: mst, jasowang, davem; +Cc: linux-kernel, netdev, virtualization, YueHaibing
Remove duplicated include linux/netdevice.h
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/virtio_net.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index eb00ae6..7659209 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -30,7 +30,6 @@
#include <linux/cpu.h>
#include <linux/average.h>
#include <linux/filter.h>
-#include <linux/netdevice.h>
#include <linux/kernel.h>
#include <linux/pci.h>
#include <net/route.h>
--
2.7.0
^ permalink raw reply related
* [PATCH] net: stmmac: Add SMC support for EMAC System Manager register
From: Ooi, Joyce @ 2018-08-13 6:41 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu
Cc: David S. Miller, netdev, linux-kernel, Ong Hean Loong,
Yves Vandervennet, Joyce Ooi
As there is restriction to access to EMAC System Manager registers in
the kernel for Intel Stratix10, the use of SMC calls are required and
added in dwmac-socfpga driver.
Signed-off-by: Ooi, Joyce <joyce.ooi@intel.com>
---
This patch is dependent on https://lkml.org/lkml/2018/7/26/624
---
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 74 +++++++++++++++++++-
1 files changed, 73 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index c3a78c1..2cea97d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -23,6 +23,9 @@
#include <linux/regmap.h>
#include <linux/reset.h>
#include <linux/stmmac.h>
+#ifdef CONFIG_HAVE_ARM_SMCCC
+#include <linux/stratix10-smc.h>
+#endif
#include "stmmac.h"
#include "stmmac_platform.h"
@@ -52,6 +55,7 @@ struct socfpga_dwmac {
int interface;
u32 reg_offset;
u32 reg_shift;
+ u32 sysmgr_reg;
struct device *dev;
struct regmap *sys_mgr_base_addr;
struct reset_control *stmmac_rst;
@@ -61,6 +65,48 @@ struct socfpga_dwmac {
struct tse_pcs pcs;
};
+#ifdef CONFIG_HAVE_ARM_SMCCC
+/**************** Stratix 10 EMAC Memory Controller Functions ************/
+
+/* s10_protected_reg_write
+ * Write to a protected SMC register.
+ * @reg: Address of register
+ * @value: Value to write
+ * Return: INTEL_SIP_SMC_STATUS_OK (0) on success
+ * INTEL_SIP_SMC_REG_ERROR on error
+ * INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION if not supported
+ */
+static int s10_protected_reg_write(unsigned int reg, unsigned int val)
+{
+ struct arm_smccc_res result;
+
+ arm_smccc_smc(INTEL_SIP_SMC_REG_WRITE, reg, val, 0, 0,
+ 0, 0, 0, &result);
+
+ return (int)result.a0;
+}
+
+/* s10_protected_reg_read
+ * Read the status of a protected SMC register
+ * @reg: Address of register
+ * @value: Value read.
+ * Return: INTEL_SIP_SMC_STATUS_OK (0) on success
+ * INTEL_SIP_SMC_REG_ERROR on error
+ * INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION if not supported
+ */
+static int s10_protected_reg_read(unsigned int reg, unsigned int *val)
+{
+ struct arm_smccc_res result;
+
+ arm_smccc_smc(INTEL_SIP_SMC_REG_READ, reg, 0, 0, 0,
+ 0, 0, 0, &result);
+
+ *val = (unsigned int)result.a1;
+
+ return (int)result.a0;
+}
+#endif
+
static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed)
{
struct socfpga_dwmac *dwmac = (struct socfpga_dwmac *)priv;
@@ -104,10 +150,11 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
{
struct device_node *np = dev->of_node;
struct regmap *sys_mgr_base_addr;
- u32 reg_offset, reg_shift;
+ u32 reg_offset, reg_shift, sysmgr_reg;
int ret, index;
struct device_node *np_splitter = NULL;
struct device_node *np_sgmii_adapter = NULL;
+ struct device_node *np_sysmgr = NULL;
struct resource res_splitter;
struct resource res_tse_pcs;
struct resource res_sgmii_adapter;
@@ -132,6 +179,16 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
return -EINVAL;
}
+ np_sysmgr = of_parse_phandle(np, "altr,sysmgr-syscon", 0);
+ if (np_sysmgr) {
+ ret = of_property_read_u32_index(np_sysmgr, "reg", 0,
+ &sysmgr_reg);
+ if (ret) {
+ dev_info(dev, "Could not read sysmgr register address\n");
+ return -EINVAL;
+ }
+ }
+
dwmac->f2h_ptp_ref_clk = of_property_read_bool(np, "altr,f2h_ptp_ref_clk");
np_splitter = of_parse_phandle(np, "altr,emac-splitter", 0);
@@ -221,6 +278,7 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
}
dwmac->reg_offset = reg_offset;
dwmac->reg_shift = reg_shift;
+ dwmac->sysmgr_reg = sysmgr_reg;
dwmac->sys_mgr_base_addr = sys_mgr_base_addr;
dwmac->dev = dev;
of_node_put(np_sgmii_adapter);
@@ -238,7 +296,9 @@ static int socfpga_dwmac_set_phy_mode(struct socfpga_dwmac *dwmac)
int phymode = dwmac->interface;
u32 reg_offset = dwmac->reg_offset;
u32 reg_shift = dwmac->reg_shift;
+ u32 sysmgr_reg = dwmac->sysmgr_reg;
u32 ctrl, val, module;
+ int ret = 0;
switch (phymode) {
case PHY_INTERFACE_MODE_RGMII:
@@ -266,7 +326,13 @@ static int socfpga_dwmac_set_phy_mode(struct socfpga_dwmac *dwmac)
reset_control_assert(dwmac->stmmac_ocp_rst);
reset_control_assert(dwmac->stmmac_rst);
+#ifdef CONFIG_HAVE_ARM_SMCCC
+ ret = s10_protected_reg_read(sysmgr_reg + reg_offset, &ctrl);
+ if (ret)
+ dev_err(dwmac->dev, "error reading Sys Mgr %d\n", ret);
+#else
regmap_read(sys_mgr_base_addr, reg_offset, &ctrl);
+#endif
ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << reg_shift);
ctrl |= val << reg_shift;
@@ -281,7 +347,13 @@ static int socfpga_dwmac_set_phy_mode(struct socfpga_dwmac *dwmac)
ctrl &= ~(SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK << (reg_shift / 2));
}
+#ifdef CONFIG_HAVE_ARM_SMCCC
+ ret = s10_protected_reg_write(sysmgr_reg + reg_offset, ctrl);
+ if (ret)
+ dev_err(dwmac->dev, "error writing Sys Mgr %d\n", ret);
+#else
regmap_write(sys_mgr_base_addr, reg_offset, ctrl);
+#endif
/* Deassert reset for the phy configuration to be sampled by
* the enet controller, and operation to start in requested mode
--
1.7.1
^ permalink raw reply related
* [PATCH] cxgb4: remove set but not used variable 'spd'
From: YueHaibing @ 2018-08-13 6:48 UTC (permalink / raw)
To: ganeshgr, davem; +Cc: linux-kernel, netdev, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function 'print_port_info':
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:5147:14: warning:
variable 'spd' set but not used [-Wunused-but-set-variable]
variable 'spd' is set but not used since
commit 547fd27241a8 ("cxgb4: Warn if device doesn't have enough PCI bandwidth")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 69590cf..961e3087 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -5144,17 +5144,9 @@ static void print_port_info(const struct net_device *dev)
{
char buf[80];
char *bufp = buf;
- const char *spd = "";
const struct port_info *pi = netdev_priv(dev);
const struct adapter *adap = pi->adapter;
- if (adap->params.pci.speed == PCI_EXP_LNKSTA_CLS_2_5GB)
- spd = " 2.5 GT/s";
- else if (adap->params.pci.speed == PCI_EXP_LNKSTA_CLS_5_0GB)
- spd = " 5 GT/s";
- else if (adap->params.pci.speed == PCI_EXP_LNKSTA_CLS_8_0GB)
- spd = " 8 GT/s";
-
if (pi->link_cfg.pcaps & FW_PORT_CAP32_SPEED_100M)
bufp += sprintf(bufp, "100M/");
if (pi->link_cfg.pcaps & FW_PORT_CAP32_SPEED_1G)
--
2.7.0
^ permalink raw reply related
* Re: [PATCH] cxgb4: remove set but not used variable 'spd'
From: YueHaibing @ 2018-08-13 6:50 UTC (permalink / raw)
To: ganeshgr, davem; +Cc: linux-kernel, netdev
In-Reply-To: <20180813064851.912-1-yuehaibing@huawei.com>
Sorry, this should be for net-next
On 2018/8/13 14:48, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function 'print_port_info':
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:5147:14: warning:
> variable 'spd' set but not used [-Wunused-but-set-variable]
>
> variable 'spd' is set but not used since
> commit 547fd27241a8 ("cxgb4: Warn if device doesn't have enough PCI bandwidth")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> index 69590cf..961e3087 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
> @@ -5144,17 +5144,9 @@ static void print_port_info(const struct net_device *dev)
> {
> char buf[80];
> char *bufp = buf;
> - const char *spd = "";
> const struct port_info *pi = netdev_priv(dev);
> const struct adapter *adap = pi->adapter;
>
> - if (adap->params.pci.speed == PCI_EXP_LNKSTA_CLS_2_5GB)
> - spd = " 2.5 GT/s";
> - else if (adap->params.pci.speed == PCI_EXP_LNKSTA_CLS_5_0GB)
> - spd = " 5 GT/s";
> - else if (adap->params.pci.speed == PCI_EXP_LNKSTA_CLS_8_0GB)
> - spd = " 8 GT/s";
> -
> if (pi->link_cfg.pcaps & FW_PORT_CAP32_SPEED_100M)
> bufp += sprintf(bufp, "100M/");
> if (pi->link_cfg.pcaps & FW_PORT_CAP32_SPEED_1G)
>
^ permalink raw reply
* [PATCH net-next] cxgb4: remove set but not used variable 'spd'
From: YueHaibing @ 2018-08-13 6:59 UTC (permalink / raw)
To: ganeshgr, davem; +Cc: linux-kernel, netdev, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function 'print_port_info':
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:5147:14: warning:
variable 'spd' set but not used [-Wunused-but-set-variable]
variable 'spd' is set but not used since
commit 547fd27241a8 ("cxgb4: Warn if device doesn't have enough PCI bandwidth")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 69590cf..961e3087 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -5144,17 +5144,9 @@ static void print_port_info(const struct net_device *dev)
{
char buf[80];
char *bufp = buf;
- const char *spd = "";
const struct port_info *pi = netdev_priv(dev);
const struct adapter *adap = pi->adapter;
- if (adap->params.pci.speed == PCI_EXP_LNKSTA_CLS_2_5GB)
- spd = " 2.5 GT/s";
- else if (adap->params.pci.speed == PCI_EXP_LNKSTA_CLS_5_0GB)
- spd = " 5 GT/s";
- else if (adap->params.pci.speed == PCI_EXP_LNKSTA_CLS_8_0GB)
- spd = " 8 GT/s";
-
if (pi->link_cfg.pcaps & FW_PORT_CAP32_SPEED_100M)
bufp += sprintf(bufp, "100M/");
if (pi->link_cfg.pcaps & FW_PORT_CAP32_SPEED_1G)
--
2.7.0
^ permalink raw reply related
* [PATCH net-next] docs: net: Convert tcp.txt to RST format
From: Tobin C. Harding @ 2018-08-13 7:20 UTC (permalink / raw)
To: David S. Miller
Cc: Tobin C. Harding, Eric Dumazet, netdev, linux-doc, linux-kernel
Restructured text is the kernel documentation format of choice now.
Some text from tcp.txt is out of date, specifically the function
tcp_write() does not appear to be in the tree anymore. Also the
following data members have been removed
sk->tcp_pend_event
sk->transmit_queue
sk->transmit_new
sk->transmit_end
sk->tcp_last_tx_ack
sk->tcp_dup_ack
Remove section 'How the new TCP output machine [nyi] works'. This
leaves only a single section so we can name the document with that
section heading now.
Convert tcp.txt to RST format. Add GPLv2 SPDX tag.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
CC'd Eric as maintainer of TCP (according to MAINTAINERS)
I was going to ask a question on netdev list as to whether this file was
out of date. I just removed the suspect section and did the patch
instead. I am not sure if it is correct to remove it or if the
structure documented has just been changed. Please see bottom section
of removed text ('How the new TCP output machine [nyi] works').
Also please note this file is not covered by MAINTAINERS, should it be?
thanks,
Tobin.
Documentation/networking/00-INDEX | 2 -
Documentation/networking/index.rst | 1 +
Documentation/networking/tcp.rst | 71 ++++++++++++++++++++
Documentation/networking/tcp.txt | 101 -----------------------------
4 files changed, 72 insertions(+), 103 deletions(-)
create mode 100644 Documentation/networking/tcp.rst
delete mode 100644 Documentation/networking/tcp.txt
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index 02a323c43261..dcbccae4043e 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -198,8 +198,6 @@ tc-actions-env-rules.txt
- rules for traffic control (tc) actions.
timestamping.txt
- overview of network packet timestamping variants.
-tcp.txt
- - short blurb on how TCP output takes place.
tcp-thin.txt
- kernel tuning options for low rate 'thin' TCP streams.
team.txt
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index fcd710f2cc7a..1cb9bcc36dd7 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -21,6 +21,7 @@ Contents:
net_failover
alias
bridge
+ tcp
.. only:: subproject
diff --git a/Documentation/networking/tcp.rst b/Documentation/networking/tcp.rst
new file mode 100644
index 000000000000..ae2094fc5de3
--- /dev/null
+++ b/Documentation/networking/tcp.rst
@@ -0,0 +1,71 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================
+TCP Congestion Control
+======================
+
+The following variables are used in the tcp_sock for congestion control
+
+.. flat-table:: Congestion Control
+ :widths: 1 2
+
+ * - tcp_sock struct member
+ - Usage
+
+ * - snd_cwnd
+ - The size of the congestion window
+
+ * - snd_ssthresh
+ - Slow start threshold. We are in slow start if snd_cwnd is less
+ than this.
+
+ * - snd_cwnd_cnt
+ - A counter used to slow down the rate of increase once we exceed
+ slow start threshold.
+
+ * - snd_cwnd_clamp
+ - This is the maximum size that snd_cwnd can grow to.
+
+ * - snd_cwnd_stamp
+ - Timestamp for when congestion window last validated.
+
+ * - snd_cwnd_used
+ - Used as a highwater mark for how much of the congestion window
+ is in use. It is used to adjust snd_cwnd down when the link is
+ limited by the application rather than the network.
+
+As of 2.6.13, Linux supports pluggable congestion control algorithms. A
+congestion control mechanism can be registered through functions in
+tcp_cong.c. The functions used by the congestion control mechanism are
+registered via passing a tcp_congestion_ops struct to
+tcp_register_congestion_control. As a minimum, the congestion control
+mechanism must provide a valid name and must implement either ssthresh,
+cong_avoid and undo_cwnd hooks or the "omnipotent" cong_control hook.
+
+Private data for a congestion control mechanism is stored in
+tp->ca_priv. tcp_ca(tp) returns a pointer to this space. This is
+preallocated space - it is important to check the size of your private
+data will fit this space, or alternatively, space could be allocated
+elsewhere and a pointer to it could be stored here.
+
+There are three kinds of congestion control algorithms currently: The
+simplest ones are derived from TCP reno (highspeed, scalable) and just
+provide an alternative congestion window calculation. More complex ones
+like BIC try to look at other events to provide better heuristics.
+There are also round trip time based algorithms like Vegas and
+Westwood+.
+
+Good TCP congestion control is a complex problem because the algorithm
+needs to maintain fairness and performance. Please review current
+research and RFC's before developing new modules.
+
+The default congestion control mechanism is chosen based on the
+DEFAULT_TCP_CONG Kconfig parameter. If you really want a particular
+default value then you can set it using sysctl
+net.ipv4.tcp_congestion_control. The module will be autoloaded if
+needed and you will get the expected protocol. If you ask for an
+unknown congestion method, then the sysctl attempt will fail.
+
+If you remove a TCP congestion control module, then you will get the
+next available one. Since reno cannot be built as a module, and cannot
+be removed, it will always be available.
diff --git a/Documentation/networking/tcp.txt b/Documentation/networking/tcp.txt
deleted file mode 100644
index 9c7139d57e57..000000000000
--- a/Documentation/networking/tcp.txt
+++ /dev/null
@@ -1,101 +0,0 @@
-TCP protocol
-============
-
-Last updated: 3 June 2017
-
-Contents
-========
-
-- Congestion control
-- How the new TCP output machine [nyi] works
-
-Congestion control
-==================
-
-The following variables are used in the tcp_sock for congestion control:
-snd_cwnd The size of the congestion window
-snd_ssthresh Slow start threshold. We are in slow start if
- snd_cwnd is less than this.
-snd_cwnd_cnt A counter used to slow down the rate of increase
- once we exceed slow start threshold.
-snd_cwnd_clamp This is the maximum size that snd_cwnd can grow to.
-snd_cwnd_stamp Timestamp for when congestion window last validated.
-snd_cwnd_used Used as a highwater mark for how much of the
- congestion window is in use. It is used to adjust
- snd_cwnd down when the link is limited by the
- application rather than the network.
-
-As of 2.6.13, Linux supports pluggable congestion control algorithms.
-A congestion control mechanism can be registered through functions in
-tcp_cong.c. The functions used by the congestion control mechanism are
-registered via passing a tcp_congestion_ops struct to
-tcp_register_congestion_control. As a minimum, the congestion control
-mechanism must provide a valid name and must implement either ssthresh,
-cong_avoid and undo_cwnd hooks or the "omnipotent" cong_control hook.
-
-Private data for a congestion control mechanism is stored in tp->ca_priv.
-tcp_ca(tp) returns a pointer to this space. This is preallocated space - it
-is important to check the size of your private data will fit this space, or
-alternatively, space could be allocated elsewhere and a pointer to it could
-be stored here.
-
-There are three kinds of congestion control algorithms currently: The
-simplest ones are derived from TCP reno (highspeed, scalable) and just
-provide an alternative congestion window calculation. More complex
-ones like BIC try to look at other events to provide better
-heuristics. There are also round trip time based algorithms like
-Vegas and Westwood+.
-
-Good TCP congestion control is a complex problem because the algorithm
-needs to maintain fairness and performance. Please review current
-research and RFC's before developing new modules.
-
-The default congestion control mechanism is chosen based on the
-DEFAULT_TCP_CONG Kconfig parameter. If you really want a particular default
-value then you can set it using sysctl net.ipv4.tcp_congestion_control. The
-module will be autoloaded if needed and you will get the expected protocol. If
-you ask for an unknown congestion method, then the sysctl attempt will fail.
-
-If you remove a TCP congestion control module, then you will get the next
-available one. Since reno cannot be built as a module, and cannot be
-removed, it will always be available.
-
-How the new TCP output machine [nyi] works.
-===========================================
-
-Data is kept on a single queue. The skb->users flag tells us if the frame is
-one that has been queued already. To add a frame we throw it on the end. Ack
-walks down the list from the start.
-
-We keep a set of control flags
-
-
- sk->tcp_pend_event
-
- TCP_PEND_ACK Ack needed
- TCP_ACK_NOW Needed now
- TCP_WINDOW Window update check
- TCP_WINZERO Zero probing
-
-
- sk->transmit_queue The transmission frame begin
- sk->transmit_new First new frame pointer
- sk->transmit_end Where to add frames
-
- sk->tcp_last_tx_ack Last ack seen
- sk->tcp_dup_ack Dup ack count for fast retransmit
-
-
-Frames are queued for output by tcp_write. We do our best to send the frames
-off immediately if possible, but otherwise queue and compute the body
-checksum in the copy.
-
-When a write is done we try to clear any pending events and piggy back them.
-If the window is full we queue full sized frames. On the first timeout in
-zero window we split this.
-
-On a timer we walk the retransmit list to send any retransmits, update the
-backoff timers etc. A change of route table stamp causes a change of header
-and recompute. We add any new tcp level headers and refinish the checksum
-before sending.
-
--
2.17.1
^ permalink raw reply related
* [PATCH net-next] liquidio: remove set but not used variable 'is25G'
From: YueHaibing @ 2018-08-13 7:21 UTC (permalink / raw)
To: davem, derek.chickles, satananda.burla, felix.manlunas,
raghu.vatsavayi
Cc: linux-kernel, netdev, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c: In function 'lio_set_link_ksettings':
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:392:6: warning:
variable 'is25G' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index 807ea2c..5ce604a 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -389,16 +389,13 @@ static int lio_set_link_ksettings(struct net_device *netdev,
struct lio *lio = GET_LIO(netdev);
struct oct_link_info *linfo;
struct octeon_device *oct;
- u32 is25G = 0;
oct = lio->oct_dev;
linfo = &lio->linfo;
- if (oct->subsystem_id == OCTEON_CN2350_25GB_SUBSYS_ID ||
- oct->subsystem_id == OCTEON_CN2360_25GB_SUBSYS_ID) {
- is25G = 1;
- } else {
+ if (!(oct->subsystem_id == OCTEON_CN2350_25GB_SUBSYS_ID ||
+ oct->subsystem_id == OCTEON_CN2360_25GB_SUBSYS_ID)) {
return -EOPNOTSUPP;
}
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net-next] cxgb4: remove set but not used variable 'spd'
From: Ganesh Goudar @ 2018-08-13 7:36 UTC (permalink / raw)
To: YueHaibing, davem; +Cc: linux-kernel, netdev, dt
In-Reply-To: <20180813065902.5504-1-yuehaibing@huawei.com>
On Monday, August 08/13/18, 2018 at 14:59:02 +0800, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function 'print_port_info':
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:5147:14: warning:
> variable 'spd' set but not used [-Wunused-but-set-variable]
>
> variable 'spd' is set but not used since
> commit 547fd27241a8 ("cxgb4: Warn if device doesn't have enough PCI bandwidth")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 8 --------
> 1 file changed, 8 deletions(-)
>
Thanks, YueHaibing.
Acked-by: Ganesh Goudar <ganeshgr@chelsio.com>
^ permalink raw reply
* [PATCH net-next] lan743x: lan743x: Remove duplicated include from lan743x_ptp.c
From: Yue Haibing @ 2018-08-13 6:39 UTC (permalink / raw)
To: Bryan Whitehead, Microchip Linux Driver Support, David S. Miller
Cc: Yue Haibing, netdev, kernel-janitors
Remove duplicated include.
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/microchip/lan743x_ptp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/microchip/lan743x_ptp.c b/drivers/net/ethernet/microchip/lan743x_ptp.c
index 42064fd..029a2af 100644
--- a/drivers/net/ethernet/microchip/lan743x_ptp.c
+++ b/drivers/net/ethernet/microchip/lan743x_ptp.c
@@ -6,7 +6,6 @@
#include <linux/module.h>
#include <linux/pci.h>
-#include <linux/netdevice.h>
#include <linux/net_tstamp.h>
#include "lan743x_ptp.h"
^ permalink raw reply related
* Re: [PATCH net-next] liquidio: remove set but not used variable 'is25G'
From: YueHaibing @ 2018-08-13 9:24 UTC (permalink / raw)
To: Shaikh, Shahed, davem@davemloft.net, Chickles, Derek,
Burla, Satananda, Manlunas, Felix, Vatsavayi, Raghu
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <BY2PR07MB245416297A60474BA77A99A39D390@BY2PR07MB2454.namprd07.prod.outlook.com>
On 2018/8/13 17:08, Shaikh, Shahed wrote:
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
>> Behalf Of YueHaibing
>> Sent: Monday, August 13, 2018 12:51 PM
>> To: davem@davemloft.net; Chickles, Derek <Derek.Chickles@cavium.com>;
>> Burla, Satananda <Satananda.Burla@cavium.com>; Manlunas, Felix
>> <Felix.Manlunas@cavium.com>; Vatsavayi, Raghu
>> <Raghu.Vatsavayi@cavium.com>
>> Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org; YueHaibing
>> <yuehaibing@huawei.com>
>> Subject: [PATCH net-next] liquidio: remove set but not used variable 'is25G'
>>
>> External Email
>>
>> Fixes gcc '-Wunused-but-set-variable' warning:
>>
>> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c: In function
>> 'lio_set_link_ksettings':
>> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:392:6: warning:
>> variable 'is25G' set but not used [-Wunused-but-set-variable]
>>
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>> ---
>> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 7 ++-----
>> 1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
>> b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
>> index 807ea2c..5ce604a 100644
>> --- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
>> +++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
>> @@ -389,16 +389,13 @@ static int lio_set_link_ksettings(struct net_device
>> *netdev,
>> struct lio *lio = GET_LIO(netdev);
>> struct oct_link_info *linfo;
>> struct octeon_device *oct;
>> - u32 is25G = 0;
>>
>> oct = lio->oct_dev;
>>
>> linfo = &lio->linfo;
>>
>> - if (oct->subsystem_id == OCTEON_CN2350_25GB_SUBSYS_ID ||
>> - oct->subsystem_id == OCTEON_CN2360_25GB_SUBSYS_ID) {
>> - is25G = 1;
>> - } else {
>> + if (!(oct->subsystem_id == OCTEON_CN2350_25GB_SUBSYS_ID ||
>> + oct->subsystem_id == OCTEON_CN2360_25GB_SUBSYS_ID)) {
>> return -EOPNOTSUPP;
>> }
>
> You can also remove braces which are not required for single line.
Yes, thanks. Will post v2
> Thanks,
> Shahed
>
>
>
^ permalink raw reply
* [PATCH v2 net-next] liquidio: remove set but not used variable 'is25G'
From: YueHaibing @ 2018-08-13 9:29 UTC (permalink / raw)
To: davem, derek.chickles, satananda.burla, felix.manlunas,
raghu.vatsavayi
Cc: linux-kernel, netdev, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c: In function 'lio_set_link_ksettings':
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:392:6: warning:
variable 'is25G' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
v2: remove unnecessary braces as Shahed suggested
---
drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
index 807ea2c..8e05afd 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
@@ -389,18 +389,14 @@ static int lio_set_link_ksettings(struct net_device *netdev,
struct lio *lio = GET_LIO(netdev);
struct oct_link_info *linfo;
struct octeon_device *oct;
- u32 is25G = 0;
oct = lio->oct_dev;
linfo = &lio->linfo;
- if (oct->subsystem_id == OCTEON_CN2350_25GB_SUBSYS_ID ||
- oct->subsystem_id == OCTEON_CN2360_25GB_SUBSYS_ID) {
- is25G = 1;
- } else {
+ if (!(oct->subsystem_id == OCTEON_CN2350_25GB_SUBSYS_ID ||
+ oct->subsystem_id == OCTEON_CN2360_25GB_SUBSYS_ID))
return -EOPNOTSUPP;
- }
if (oct->no_speed_setting) {
dev_err(&oct->pci_dev->dev, "%s: Changing speed is not supported\n",
--
2.7.0
^ permalink raw reply related
* Re: [PATCH net-next] virtio_net: remove duplicated include from virtio_net.c
From: Michael S. Tsirkin @ 2018-08-13 9:42 UTC (permalink / raw)
To: YueHaibing; +Cc: netdev, virtualization, davem, linux-kernel
In-Reply-To: <20180813061315.9084-1-yuehaibing@huawei.com>
On Mon, Aug 13, 2018 at 02:13:15PM +0800, YueHaibing wrote:
> Remove duplicated include linux/netdevice.h
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/virtio_net.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index eb00ae6..7659209 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -30,7 +30,6 @@
> #include <linux/cpu.h>
> #include <linux/average.h>
> #include <linux/filter.h>
> -#include <linux/netdevice.h>
> #include <linux/kernel.h>
> #include <linux/pci.h>
> #include <net/route.h>
> --
> 2.7.0
>
^ permalink raw reply
* [PATCH bpf-next V2] net/xdp: Fix suspicious RCU usage warning
From: Tariq Toukan @ 2018-08-13 7:04 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: netdev, Eran Ben Elisha, Tariq Toukan, Jesper Dangaard Brouer
Fix the warning below by calling rhashtable_lookup_fast.
Also, make some code movements for better quality and human
readability.
[ 342.450870] WARNING: suspicious RCU usage
[ 342.455856] 4.18.0-rc2+ #17 Tainted: G O
[ 342.462210] -----------------------------
[ 342.467202] ./include/linux/rhashtable.h:481 suspicious rcu_dereference_check() usage!
[ 342.476568]
[ 342.476568] other info that might help us debug this:
[ 342.476568]
[ 342.486978]
[ 342.486978] rcu_scheduler_active = 2, debug_locks = 1
[ 342.495211] 4 locks held by modprobe/3934:
[ 342.500265] #0: 00000000e23116b2 (mlx5_intf_mutex){+.+.}, at:
mlx5_unregister_interface+0x18/0x90 [mlx5_core]
[ 342.511953] #1: 00000000ca16db96 (rtnl_mutex){+.+.}, at: unregister_netdev+0xe/0x20
[ 342.521109] #2: 00000000a46e2c4b (&priv->state_lock){+.+.}, at: mlx5e_close+0x29/0x60
[mlx5_core]
[ 342.531642] #3: 0000000060c5bde3 (mem_id_lock){+.+.}, at: xdp_rxq_info_unreg+0x93/0x6b0
[ 342.541206]
[ 342.541206] stack backtrace:
[ 342.547075] CPU: 12 PID: 3934 Comm: modprobe Tainted: G O 4.18.0-rc2+ #17
[ 342.556621] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015
[ 342.565606] Call Trace:
[ 342.568861] dump_stack+0x78/0xb3
[ 342.573086] xdp_rxq_info_unreg+0x3f5/0x6b0
[ 342.578285] ? __call_rcu+0x220/0x300
[ 342.582911] mlx5e_free_rq+0x38/0xc0 [mlx5_core]
[ 342.588602] mlx5e_close_channel+0x20/0x120 [mlx5_core]
[ 342.594976] mlx5e_close_channels+0x26/0x40 [mlx5_core]
[ 342.601345] mlx5e_close_locked+0x44/0x50 [mlx5_core]
[ 342.607519] mlx5e_close+0x42/0x60 [mlx5_core]
[ 342.613005] __dev_close_many+0xb1/0x120
[ 342.617911] dev_close_many+0xa2/0x170
[ 342.622622] rollback_registered_many+0x148/0x460
[ 342.628401] ? __lock_acquire+0x48d/0x11b0
[ 342.633498] ? unregister_netdev+0xe/0x20
[ 342.638495] rollback_registered+0x56/0x90
[ 342.643588] unregister_netdevice_queue+0x7e/0x100
[ 342.649461] unregister_netdev+0x18/0x20
[ 342.654362] mlx5e_remove+0x2a/0x50 [mlx5_core]
[ 342.659944] mlx5_remove_device+0xe5/0x110 [mlx5_core]
[ 342.666208] mlx5_unregister_interface+0x39/0x90 [mlx5_core]
[ 342.673038] cleanup+0x5/0xbfc [mlx5_core]
[ 342.678094] __x64_sys_delete_module+0x16b/0x240
[ 342.683725] ? do_syscall_64+0x1c/0x210
[ 342.688476] do_syscall_64+0x5a/0x210
[ 342.693025] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes: 8d5d88527587 ("xdp: rhashtable with allocator ID to pointer mapping")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/core/xdp.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
V1 -> V2:
* Use rhashtable_lookup_fast and make some code movements, per Daniel's
and Alexei's comments.
Please queue to -stable v4.18.
diff --git a/net/core/xdp.c b/net/core/xdp.c
index 3dd99e1c04f5..8b1c7b699982 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -105,16 +105,9 @@ static void __xdp_rxq_info_unreg_mem_model(struct xdp_rxq_info *xdp_rxq)
mutex_lock(&mem_id_lock);
- xa = rhashtable_lookup(mem_id_ht, &id, mem_id_rht_params);
- if (!xa) {
- mutex_unlock(&mem_id_lock);
- return;
- }
-
- err = rhashtable_remove_fast(mem_id_ht, &xa->node, mem_id_rht_params);
- WARN_ON(err);
-
- call_rcu(&xa->rcu, __xdp_mem_allocator_rcu_free);
+ xa = rhashtable_lookup_fast(mem_id_ht, &id, mem_id_rht_params);
+ if (xa && rhashtable_remove_fast(mem_id_ht, &xa->node, mem_id_rht_params))
+ call_rcu(&xa->rcu, __xdp_mem_allocator_rcu_free);
mutex_unlock(&mem_id_lock);
}
--
1.8.3.1
^ permalink raw reply related
* the mobile apps
From: Jack Dike @ 2018-08-13 6:14 UTC (permalink / raw)
To: netdev
Do you need mobile apps development? We can do it for you.
We are an India base company. Here are the details about us:
Years in business: 8
Staffs: 125
App developed: 350
We work on Android, iOS, Ionic, and PhoneGap platforms, we have clients
across different kind of industries.
Such like retail, media and entertainment, BFSI, hospitality, social media,
eCommerce, food and beverages, etc.
We do below:
Mobile Apps
Mobile App UI/UX designing
App Maintenance and Support
Website or ecommerce portal development
Please reply back if you are interested in what we do.
We will share our portfolios to you.
Regards,
Jack
^ permalink raw reply
* you need mobile apps
From: Jack Dike @ 2018-08-13 5:38 UTC (permalink / raw)
To: netdev
Do you need mobile apps development? We can do it for you.
We are an India base company. Here are the details about us:
Years in business: 8
Staffs: 125
App developed: 350
We work on Android, iOS, Ionic, and PhoneGap platforms, we have clients
across different kind of industries.
Such like retail, media and entertainment, BFSI, hospitality, social media,
eCommerce, food and beverages, etc.
We do below:
Mobile Apps
Mobile App UI/UX designing
App Maintenance and Support
Website or ecommerce portal development
Please reply back if you are interested in what we do.
We will share our portfolios to you.
Regards,
Jack
^ permalink raw reply
* Re: [PATCH net-next v6 10/11] net: sched: atomically check-allocate action
From: Vlad Buslov @ 2018-08-13 7:55 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
Jiri Pirko, Alexei Starovoitov, Daniel Borkmann,
Yevgeny Kliteynik, Jiri Pirko
In-Reply-To: <CAM_iQpW2GAFY84K9pDjcXiRB9VVYKdEHBU6mGu83hLyexahaqw@mail.gmail.com>
On Fri 10 Aug 2018 at 21:45, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Fri, Aug 10, 2018 at 3:29 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>>
>> Approach you suggest is valid, but has its own trade-offs:
>>
>> - As you noted, lock granularity becomes coarse-grained due to per-netns
>> scope.
>
> Sure, you acquire idrinfo->lock too, the only difference is how long
> you take it.
>
> The bottleneck of your approach is the same, also you take idrinfo->lock
> twice, so the contention is heavier.
>
>
>>
>> - I am not sure it is possible to call idr_replace() without obtaining
>> idrinfo->lock in this particular case. Concurrent delete of action with
>> same id is possible and, according to idr_replace() description,
>> unlocked execution is not supported for such use-case:
>
> But we can hold its refcnt before releasing idrinfo->lock, so
> idr_replace() can't race with concurrent delete.
Yes, for concurrent delete case I agree. Action is removed from idr only
when last reference is released and, in case of existing action update,
init holds a reference.
What about case when multiple task race to update the same existing
action? I assume idr_replace() can be used for such case, but what would
be the algorithm in case init replaced some other action, and not the
action it actually copied before calling idr_replace()?
>
>
>>
>> - High rate or replace request will generate a lot of unnecessary memory
>> allocations and deallocations.
>>
>
> Yes, this is literally how RCU works, always allocate and copy,
> release upon error.
>
> Also, if this is really a problem, we have SLAB_TYPESAFE_BY_RCU
> too. ;)
Current action update implementation is in-place, so there is no "copy"
stage, besides members of some actions that are RCU-pointers. But I
guess it makes sense if your goal is to refactor all actions to be
updated with RCU.
^ permalink raw reply
* RE: [PATCH] net/phy: Micrel KSZ8061 PHY link failure after cable connect
From: Onnasch, Alexander (EXT) @ 2018-08-13 10:41 UTC (permalink / raw)
To: David Miller
Cc: andrew@lunn.ch, f.fainelli@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20180730.094534.351189879060038512.davem@davemloft.net>
-----Original Message-----
From: David Miller <davem@davemloft.net>
Sent: Montag, 30. Juli 2018 18:46
To: Onnasch, Alexander (EXT) <Alexander.Onnasch@landisgyr.com>
Cc: andrew@lunn.ch; f.fainelli@gmail.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net/phy: Micrel KSZ8061 PHY link failure after cable connect
From: Alexander Onnasch <alexander.onnasch@landisgyr.com>
Date: Mon, 30 Jul 2018 16:01:27 +0200
> With Micrel KSZ8061 PHY, the link may occasionally not come up after
> Ethernet cable connect. The vendor's (Microchip, former Micrel) errata
> sheet 80000688A.pdf describes the problem and possible workarounds in
> detail, see below.
> The patch implements workaround 1, which permanently fixes the issue.
...
> Signed-off-by: Alexander Onnasch <alexander.onnasch@landisgyr.com>
This patch does not apply cleanly to any of my neworking trees.
Hello David
thanks a lot for reviewing ! How to proceed now ? If there is action required from my side please tell me.
best regards,
Alex
Alexander Onnasch | Landis+Gyr AG | Firmware Engineer
Phone: +41 41 935 6357 | Fax: +41 41 935 6211
Email: alexander.onnasch@landisgyr.com | Site: www.landisgyr.com | Address: Theilerstr. 1, CH-6301 Zug, Switzerland
manage energy better
^ permalink raw reply
* Re: [PATCH] mt76: Enable NL80211_EXT_FEATURE_CQM_RSSI_LIST
From: Lorenzo Bianconi @ 2018-08-13 10:55 UTC (permalink / raw)
To: arend.vanspriel-dY08KVG/lbpWk0Htik3J/w
Cc: Kalle Valo, kristian.evensen-Re5JQEeQqe8AvxtiuMwx3w,
linux-wireless, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <5B708025.4090906-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> On 8/12/2018 8:14 PM, Kalle Valo wrote:
> > Kristian Evensen <kristian.evensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> >
> >> Enable the use of CQM with mt76-devices.
> >>
> >> Signed-off-by: Kristian Evensen <kristian.evensen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> ---
> >> drivers/net/wireless/mediatek/mt76/mac80211.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
> >> index 029d54bc..3eb328ff 100644
> >> --- a/drivers/net/wireless/mediatek/mt76/mac80211.c
> >> +++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
> >> @@ -305,6 +305,8 @@ int mt76_register_device(struct mt76_dev *dev, bool vht,
> >>
> >> wiphy->features |= NL80211_FEATURE_ACTIVE_MONITOR;
> >>
> >> + wiphy_ext_feature_set(wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST);
> >
> > So have you tested this and with what devices? For example, does it work
> > with recently added USB devices?
>
> I was looking into this as it looks suspicious to me. From reading the
> description of this ext_feature flag it seems this is an extention of CQM:
>
> """
> * @NL80211_EXT_FEATURE_CQM_RSSI_LIST: With this driver the
> * %NL80211_ATTR_CQM_RSSI_THOLD attribute accepts a list of zero or more
> * RSSI threshold values to monitor rather than exactly one threshold.
> """
>
> Also looking at mt76x2_bss_info_changed() it does not handle
> BSS_CHANGED_CQM so I doubt it has support for it (yet). The driver does
> not use IEEE80211_VIF_SUPPORTS_CQM_RSSI which is a requirement for it.
>
> Regards,
> Arend
>
According to my understanding (please correct me if I am wrong)
BSS_CHANGED_CQM is only needed if CQM_RSSI is handled
by the driver/fw, while if it is not set mac80211 will take care of that
in ieee80211_handle_beacon_sig routine.
I am AFK at the moment, I will test that patch when I am back from vacations.
Regards,
Lorenzo
>
> https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/mediatek/mt76/mt76x2_main.c#L223
>
^ permalink raw reply
* Re: [PATCH] net: macb: do not disable MDIO bus when closing interface
From: Claudiu Beznea @ 2018-08-13 9:08 UTC (permalink / raw)
To: Anssi Hannula, Andrew Lunn; +Cc: Nicolas Ferre, David S. Miller, netdev
In-Reply-To: <edd7aaf4-53dc-6d10-5c4b-2928a4612d99@bitwise.fi>
On 10.08.2018 09:22, Anssi Hannula wrote:
> On 9.8.2018 18:14, Andrew Lunn wrote:
>> Hi Anssi
>
> Hi!
>
>>> macb_reset_hw() is called in init path too,
I only see it in macb_close() and macb_open() called from macb_init_hw().
though, so maybe clearing
>>> all bits is intentional / wanted to get the controller to a known state,
As far as I know the NCR is used in this driver only to control transmit
enable, receive enable, MPE and tx start.
Not clearing NCR in the init phase should not have any impact on IP. Same
for not clearing Tx start on "if down" path (if tx is in progress).
>>> even though the comment only mentions TX/RX?
>> You need to be careful here. Once of_mdiobus_register() is called, the
>> MDIO should be usable. If you happen to have an Ethernet switch on the
>> bus, it could be probed then. The DSA driver will start using the bus.
>> Or if you have a second PHY, connected to some other MAC, it could be
>> used by the other MAC. This all happens in the macb_probe function.
>>
>> Sometime later, the interface will be up'ed. At this point macb_open()
>> is called, which calls macb_init_hw(), which calls
>> macb_reset_hw(). What you don't want happening is changes to the NCR
>> at this point breaking an MDIO transaction which might be going on.
>>
>> Ideally, the MPE should be enabled before of_mdiobus_register(), and
>> left alone until mdiobus_unregister() is called in macb_remove().
>
> Yep, fixing the use case of having PHYs of other MACs is why I wrote the
> patch :)
>
> Currently the reset code disables MPE while other MACs are using PHYs on
> the bus.
MPE is set in the early phase of initialization, in macb_mii_init(), called
from probe() function. Due to the fact that NCR is cleared in
macb_reset_hw() it is set again at the end of macb_init_hw(). So, as per
Andrew comments in this thread, setting it in macb_mii_init() and letting
it unchanged until remove would be the best. So, if you clear only TE and
RE bits in macb_reset_hw() please also remove MACB_BIT(MPE) from below line
at the end of macb_init_hw():
macb_writel(bp, NCR, MACB_BIT(RE) | MACB_BIT(TE) | MACB_BIT(MPE));
Thank you,
Claudiu Beznea
>
^ permalink raw reply
* RE: [PATCH net-next] liquidio: remove set but not used variable 'is25G'
From: Shaikh, Shahed @ 2018-08-13 9:08 UTC (permalink / raw)
To: YueHaibing, davem@davemloft.net, Chickles, Derek,
Burla, Satananda, Manlunas, Felix, Vatsavayi, Raghu
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20180813072118.12448-1-yuehaibing@huawei.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> Behalf Of YueHaibing
> Sent: Monday, August 13, 2018 12:51 PM
> To: davem@davemloft.net; Chickles, Derek <Derek.Chickles@cavium.com>;
> Burla, Satananda <Satananda.Burla@cavium.com>; Manlunas, Felix
> <Felix.Manlunas@cavium.com>; Vatsavayi, Raghu
> <Raghu.Vatsavayi@cavium.com>
> Cc: linux-kernel@vger.kernel.org; netdev@vger.kernel.org; YueHaibing
> <yuehaibing@huawei.com>
> Subject: [PATCH net-next] liquidio: remove set but not used variable 'is25G'
>
> External Email
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c: In function
> 'lio_set_link_ksettings':
> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c:392:6: warning:
> variable 'is25G' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/ethernet/cavium/liquidio/lio_ethtool.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
> b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
> index 807ea2c..5ce604a 100644
> --- a/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
> +++ b/drivers/net/ethernet/cavium/liquidio/lio_ethtool.c
> @@ -389,16 +389,13 @@ static int lio_set_link_ksettings(struct net_device
> *netdev,
> struct lio *lio = GET_LIO(netdev);
> struct oct_link_info *linfo;
> struct octeon_device *oct;
> - u32 is25G = 0;
>
> oct = lio->oct_dev;
>
> linfo = &lio->linfo;
>
> - if (oct->subsystem_id == OCTEON_CN2350_25GB_SUBSYS_ID ||
> - oct->subsystem_id == OCTEON_CN2360_25GB_SUBSYS_ID) {
> - is25G = 1;
> - } else {
> + if (!(oct->subsystem_id == OCTEON_CN2350_25GB_SUBSYS_ID ||
> + oct->subsystem_id == OCTEON_CN2360_25GB_SUBSYS_ID)) {
> return -EOPNOTSUPP;
> }
You can also remove braces which are not required for single line.
Thanks,
Shahed
^ permalink raw reply
* Re: [PATCH bpf-next V2] net/xdp: Fix suspicious RCU usage warning
From: Jesper Dangaard Brouer @ 2018-08-13 9:13 UTC (permalink / raw)
To: Tariq Toukan
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, Eran Ben Elisha,
brouer
In-Reply-To: <1534143879-8380-1-git-send-email-tariqt@mellanox.com>
On Mon, 13 Aug 2018 10:04:39 +0300
Tariq Toukan <tariqt@mellanox.com> wrote:
> Fix the warning below by calling rhashtable_lookup_fast.
> Also, make some code movements for better quality and human
> readability.
>
> [ 342.450870] WARNING: suspicious RCU usage
> [ 342.455856] 4.18.0-rc2+ #17 Tainted: G O
> [ 342.462210] -----------------------------
> [ 342.467202] ./include/linux/rhashtable.h:481 suspicious rcu_dereference_check() usage!
> [ 342.476568]
> [ 342.476568] other info that might help us debug this:
> [ 342.476568]
> [ 342.486978]
> [ 342.486978] rcu_scheduler_active = 2, debug_locks = 1
> [ 342.495211] 4 locks held by modprobe/3934:
> [ 342.500265] #0: 00000000e23116b2 (mlx5_intf_mutex){+.+.}, at:
> mlx5_unregister_interface+0x18/0x90 [mlx5_core]
> [ 342.511953] #1: 00000000ca16db96 (rtnl_mutex){+.+.}, at: unregister_netdev+0xe/0x20
> [ 342.521109] #2: 00000000a46e2c4b (&priv->state_lock){+.+.}, at: mlx5e_close+0x29/0x60
> [mlx5_core]
> [ 342.531642] #3: 0000000060c5bde3 (mem_id_lock){+.+.}, at: xdp_rxq_info_unreg+0x93/0x6b0
> [ 342.541206]
> [ 342.541206] stack backtrace:
> [ 342.547075] CPU: 12 PID: 3934 Comm: modprobe Tainted: G O 4.18.0-rc2+ #17
> [ 342.556621] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015
> [ 342.565606] Call Trace:
> [ 342.568861] dump_stack+0x78/0xb3
> [ 342.573086] xdp_rxq_info_unreg+0x3f5/0x6b0
> [ 342.578285] ? __call_rcu+0x220/0x300
> [ 342.582911] mlx5e_free_rq+0x38/0xc0 [mlx5_core]
> [ 342.588602] mlx5e_close_channel+0x20/0x120 [mlx5_core]
> [ 342.594976] mlx5e_close_channels+0x26/0x40 [mlx5_core]
> [ 342.601345] mlx5e_close_locked+0x44/0x50 [mlx5_core]
> [ 342.607519] mlx5e_close+0x42/0x60 [mlx5_core]
> [ 342.613005] __dev_close_many+0xb1/0x120
> [ 342.617911] dev_close_many+0xa2/0x170
> [ 342.622622] rollback_registered_many+0x148/0x460
> [ 342.628401] ? __lock_acquire+0x48d/0x11b0
> [ 342.633498] ? unregister_netdev+0xe/0x20
> [ 342.638495] rollback_registered+0x56/0x90
> [ 342.643588] unregister_netdevice_queue+0x7e/0x100
> [ 342.649461] unregister_netdev+0x18/0x20
> [ 342.654362] mlx5e_remove+0x2a/0x50 [mlx5_core]
> [ 342.659944] mlx5_remove_device+0xe5/0x110 [mlx5_core]
> [ 342.666208] mlx5_unregister_interface+0x39/0x90 [mlx5_core]
> [ 342.673038] cleanup+0x5/0xbfc [mlx5_core]
> [ 342.678094] __x64_sys_delete_module+0x16b/0x240
> [ 342.683725] ? do_syscall_64+0x1c/0x210
> [ 342.688476] do_syscall_64+0x5a/0x210
> [ 342.693025] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Fixes: 8d5d88527587 ("xdp: rhashtable with allocator ID to pointer mapping")
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
> net/core/xdp.c | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> V1 -> V2:
> * Use rhashtable_lookup_fast and make some code movements, per Daniel's
> and Alexei's comments.
>
> Please queue to -stable v4.18.
>
> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 3dd99e1c04f5..8b1c7b699982 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -105,16 +105,9 @@ static void __xdp_rxq_info_unreg_mem_model(struct xdp_rxq_info *xdp_rxq)
>
> mutex_lock(&mem_id_lock);
>
> - xa = rhashtable_lookup(mem_id_ht, &id, mem_id_rht_params);
> - if (!xa) {
> - mutex_unlock(&mem_id_lock);
> - return;
> - }
> -
> - err = rhashtable_remove_fast(mem_id_ht, &xa->node, mem_id_rht_params);
> - WARN_ON(err);
> -
> - call_rcu(&xa->rcu, __xdp_mem_allocator_rcu_free);
> + xa = rhashtable_lookup_fast(mem_id_ht, &id, mem_id_rht_params);
> + if (xa && rhashtable_remove_fast(mem_id_ht, &xa->node, mem_id_rht_params))
> + call_rcu(&xa->rcu, __xdp_mem_allocator_rcu_free);
>
> mutex_unlock(&mem_id_lock);
> }
This is wrong.
The function rhashtable_remove_fast() returns zero on success.
Please, fix and send a V3.
Look at example in [1] section "Object removal"
[1] https://lwn.net/Articles/751374/
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* mobile apps for you
From: Jack Dike @ 2018-08-13 6:29 UTC (permalink / raw)
To: netdev
Do you need mobile apps development? We can do it for you.
We are an India base company. Here are the details about us:
Years in business: 8
Staffs: 125
App developed: 350
We work on Android, iOS, Ionic, and PhoneGap platforms, we have clients
across different kind of industries.
Such like retail, media and entertainment, BFSI, hospitality, social media,
eCommerce, food and beverages, etc.
We do below:
Mobile Apps
Mobile App UI/UX designing
App Maintenance and Support
Website or ecommerce portal development
Please reply back if you are interested in what we do.
We will share our portfolios to you.
Regards,
Jack
^ permalink raw reply
* mobile apps for you
From: Jack Dike @ 2018-08-13 6:29 UTC (permalink / raw)
To: netdev
Do you need mobile apps development? We can do it for you.
We are an India base company. Here are the details about us:
Years in business: 8
Staffs: 125
App developed: 350
We work on Android, iOS, Ionic, and PhoneGap platforms, we have clients
across different kind of industries.
Such like retail, media and entertainment, BFSI, hospitality, social media,
eCommerce, food and beverages, etc.
We do below:
Mobile Apps
Mobile App UI/UX designing
App Maintenance and Support
Website or ecommerce portal development
Please reply back if you are interested in what we do.
We will share our portfolios to you.
Regards,
Jack
^ permalink raw reply
* [PATCH bpf-next V3] net/xdp: Fix suspicious RCU usage warning
From: Tariq Toukan @ 2018-08-13 9:21 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: netdev, Eran Ben Elisha, Tariq Toukan, Jesper Dangaard Brouer
Fix the warning below by calling rhashtable_lookup_fast.
Also, make some code movements for better quality and human
readability.
[ 342.450870] WARNING: suspicious RCU usage
[ 342.455856] 4.18.0-rc2+ #17 Tainted: G O
[ 342.462210] -----------------------------
[ 342.467202] ./include/linux/rhashtable.h:481 suspicious rcu_dereference_check() usage!
[ 342.476568]
[ 342.476568] other info that might help us debug this:
[ 342.476568]
[ 342.486978]
[ 342.486978] rcu_scheduler_active = 2, debug_locks = 1
[ 342.495211] 4 locks held by modprobe/3934:
[ 342.500265] #0: 00000000e23116b2 (mlx5_intf_mutex){+.+.}, at:
mlx5_unregister_interface+0x18/0x90 [mlx5_core]
[ 342.511953] #1: 00000000ca16db96 (rtnl_mutex){+.+.}, at: unregister_netdev+0xe/0x20
[ 342.521109] #2: 00000000a46e2c4b (&priv->state_lock){+.+.}, at: mlx5e_close+0x29/0x60
[mlx5_core]
[ 342.531642] #3: 0000000060c5bde3 (mem_id_lock){+.+.}, at: xdp_rxq_info_unreg+0x93/0x6b0
[ 342.541206]
[ 342.541206] stack backtrace:
[ 342.547075] CPU: 12 PID: 3934 Comm: modprobe Tainted: G O 4.18.0-rc2+ #17
[ 342.556621] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015
[ 342.565606] Call Trace:
[ 342.568861] dump_stack+0x78/0xb3
[ 342.573086] xdp_rxq_info_unreg+0x3f5/0x6b0
[ 342.578285] ? __call_rcu+0x220/0x300
[ 342.582911] mlx5e_free_rq+0x38/0xc0 [mlx5_core]
[ 342.588602] mlx5e_close_channel+0x20/0x120 [mlx5_core]
[ 342.594976] mlx5e_close_channels+0x26/0x40 [mlx5_core]
[ 342.601345] mlx5e_close_locked+0x44/0x50 [mlx5_core]
[ 342.607519] mlx5e_close+0x42/0x60 [mlx5_core]
[ 342.613005] __dev_close_many+0xb1/0x120
[ 342.617911] dev_close_many+0xa2/0x170
[ 342.622622] rollback_registered_many+0x148/0x460
[ 342.628401] ? __lock_acquire+0x48d/0x11b0
[ 342.633498] ? unregister_netdev+0xe/0x20
[ 342.638495] rollback_registered+0x56/0x90
[ 342.643588] unregister_netdevice_queue+0x7e/0x100
[ 342.649461] unregister_netdev+0x18/0x20
[ 342.654362] mlx5e_remove+0x2a/0x50 [mlx5_core]
[ 342.659944] mlx5_remove_device+0xe5/0x110 [mlx5_core]
[ 342.666208] mlx5_unregister_interface+0x39/0x90 [mlx5_core]
[ 342.673038] cleanup+0x5/0xbfc [mlx5_core]
[ 342.678094] __x64_sys_delete_module+0x16b/0x240
[ 342.683725] ? do_syscall_64+0x1c/0x210
[ 342.688476] do_syscall_64+0x5a/0x210
[ 342.693025] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Fixes: 8d5d88527587 ("xdp: rhashtable with allocator ID to pointer mapping")
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
---
net/core/xdp.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
V2 -> V3:
* Fix return value test for rhashtable_remove_fast, per Jesper's comment.
V1 -> V2:
* Use rhashtable_lookup_fast and make some code movements, per Daniel's
and Alexei's comments.
Please queue to -stable v4.18.
diff --git a/net/core/xdp.c b/net/core/xdp.c
index 3dd99e1c04f5..8b1c7b699982 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -105,16 +105,9 @@ static void __xdp_rxq_info_unreg_mem_model(struct xdp_rxq_info *xdp_rxq)
mutex_lock(&mem_id_lock);
- xa = rhashtable_lookup(mem_id_ht, &id, mem_id_rht_params);
- if (!xa) {
- mutex_unlock(&mem_id_lock);
- return;
- }
-
- err = rhashtable_remove_fast(mem_id_ht, &xa->node, mem_id_rht_params);
- WARN_ON(err);
-
- call_rcu(&xa->rcu, __xdp_mem_allocator_rcu_free);
+ xa = rhashtable_lookup_fast(mem_id_ht, &id, mem_id_rht_params);
+ if (xa && !rhashtable_remove_fast(mem_id_ht, &xa->node, mem_id_rht_params))
+ call_rcu(&xa->rcu, __xdp_mem_allocator_rcu_free);
mutex_unlock(&mem_id_lock);
}
--
1.8.3.1
^ permalink raw reply related
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