* [PATCH net-next] net/ncsi: Add NCSI Mellanox OEM command
From: Vijay Khemka @ 2018-11-20 20:35 UTC (permalink / raw)
To: Samuel Mendoza-Jonas, David S. Miller, netdev, linux-kernel
Cc: vijaykhemka, openbmc @ lists . ozlabs . org, Justin.Lee1, joel,
linux-aspeed
This patch adds OEM Mellanox commands and response handling. It also
defines OEM Get MAC Address handler to get and configure the device.
ncsi_oem_gma_handler_mlx: This handler send NCSI mellanox command for
getting mac address.
ncsi_rsp_handler_oem_mlx: This handles response received for all
mellanox OEM commands.
ncsi_rsp_handler_oem_mlx_gma: This handles get mac address response and
set it to device.
Signed-off-by: Vijay Khemka <vijaykhemka@fb.com>
---
net/ncsi/internal.h | 5 +++++
net/ncsi/ncsi-manage.c | 25 ++++++++++++++++++++++++-
net/ncsi/ncsi-pkt.h | 9 +++++++++
net/ncsi/ncsi-rsp.c | 41 ++++++++++++++++++++++++++++++++++++++++-
4 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/net/ncsi/internal.h b/net/ncsi/internal.h
index 1dae77c54009..7f3eb1360b9b 100644
--- a/net/ncsi/internal.h
+++ b/net/ncsi/internal.h
@@ -73,10 +73,15 @@ enum {
#define NCSI_OEM_MFR_BCM_ID 0x113d
/* Broadcom specific OEM Command */
#define NCSI_OEM_BCM_CMD_GMA 0x01 /* CMD ID for Get MAC */
+/* Mellanox specific OEM Command */
+#define NCSI_OEM_MLX_CMD_GMA 0x00 /* CMD ID for Get MAC */
+#define NCSI_OEM_MLX_CMD_GMA_PARAM 0x1b /* Parameter for GMA */
/* OEM Command payload lengths*/
#define NCSI_OEM_BCM_CMD_GMA_LEN 12
+#define NCSI_OEM_MLX_CMD_GMA_LEN 8
/* Mac address offset in OEM response */
#define BCM_MAC_ADDR_OFFSET 28
+#define MLX_MAC_ADDR_OFFSET 8
struct ncsi_channel_version {
diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c
index bfc43b28c7a6..eacb653ff987 100644
--- a/net/ncsi/ncsi-manage.c
+++ b/net/ncsi/ncsi-manage.c
@@ -675,12 +675,35 @@ static int ncsi_oem_gma_handler_bcm(struct ncsi_cmd_arg *nca)
return ret;
}
+static int ncsi_oem_gma_handler_mlx(struct ncsi_cmd_arg *nca)
+{
+ unsigned char data[NCSI_OEM_MLX_CMD_GMA_LEN];
+ int ret = 0;
+
+ nca->payload = NCSI_OEM_MLX_CMD_GMA_LEN;
+
+ memset(data, 0, NCSI_OEM_MLX_CMD_GMA_LEN);
+ *(unsigned int *)data = ntohl(NCSI_OEM_MFR_MLX_ID);
+ data[5] = NCSI_OEM_MLX_CMD_GMA;
+ data[6] = NCSI_OEM_MLX_CMD_GMA_PARAM;
+
+ nca->data = data;
+
+ ret = ncsi_xmit_cmd(nca);
+ if (ret)
+ netdev_err(nca->ndp->ndev.dev,
+ "NCSI: Failed to transmit cmd 0x%x during configure\n",
+ nca->type);
+ return ret;
+}
+
/* OEM Command handlers initialization */
static struct ncsi_oem_gma_handler {
unsigned int mfr_id;
int (*handler)(struct ncsi_cmd_arg *nca);
} ncsi_oem_gma_handlers[] = {
- { NCSI_OEM_MFR_BCM_ID, ncsi_oem_gma_handler_bcm }
+ { NCSI_OEM_MFR_BCM_ID, ncsi_oem_gma_handler_bcm },
+ { NCSI_OEM_MFR_MLX_ID, ncsi_oem_gma_handler_mlx }
};
static int ncsi_gma_handler(struct ncsi_cmd_arg *nca, unsigned int mf_id)
diff --git a/net/ncsi/ncsi-pkt.h b/net/ncsi/ncsi-pkt.h
index 4d3f06be38bd..2a6d83a596c9 100644
--- a/net/ncsi/ncsi-pkt.h
+++ b/net/ncsi/ncsi-pkt.h
@@ -165,6 +165,15 @@ struct ncsi_rsp_oem_pkt {
unsigned char data[]; /* Payload data */
};
+/* Mellanox Response Data */
+struct ncsi_rsp_oem_mlx_pkt {
+ unsigned char cmd_rev; /* Command Revision */
+ unsigned char cmd; /* Command ID */
+ unsigned char param; /* Parameter */
+ unsigned char optional; /* Optional data */
+ unsigned char data[]; /* Data */
+};
+
/* Broadcom Response Data */
struct ncsi_rsp_oem_bcm_pkt {
unsigned char ver; /* Payload Version */
diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c
index 77e07ba3f493..ba9a4ba97c64 100644
--- a/net/ncsi/ncsi-rsp.c
+++ b/net/ncsi/ncsi-rsp.c
@@ -611,6 +611,45 @@ static int ncsi_rsp_handler_snfc(struct ncsi_request *nr)
return 0;
}
+/* Response handler for Mellanox command Get Mac Address */
+static int ncsi_rsp_handler_oem_mlx_gma(struct ncsi_request *nr)
+{
+ struct ncsi_dev_priv *ndp = nr->ndp;
+ struct net_device *ndev = ndp->ndev.dev;
+ const struct net_device_ops *ops = ndev->netdev_ops;
+ struct ncsi_rsp_oem_pkt *rsp;
+ struct sockaddr saddr;
+ int ret = 0;
+
+ /* Get the response header */
+ rsp = (struct ncsi_rsp_oem_pkt *)skb_network_header(nr->rsp);
+
+ saddr.sa_family = ndev->type;
+ ndev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
+ memcpy(saddr.sa_data, &rsp->data[MLX_MAC_ADDR_OFFSET], ETH_ALEN);
+ ret = ops->ndo_set_mac_address(ndev, &saddr);
+ if (ret < 0)
+ netdev_warn(ndev, "NCSI: 'Writing mac address to device failed\n");
+
+ return ret;
+}
+
+/* Response handler for Mellanox card */
+static int ncsi_rsp_handler_oem_mlx(struct ncsi_request *nr)
+{
+ struct ncsi_rsp_oem_mlx_pkt *mlx;
+ struct ncsi_rsp_oem_pkt *rsp;
+
+ /* Get the response header */
+ rsp = (struct ncsi_rsp_oem_pkt *)skb_network_header(nr->rsp);
+ mlx = (struct ncsi_rsp_oem_mlx_pkt *)(rsp->data);
+
+ if (mlx->cmd == NCSI_OEM_MLX_CMD_GMA &&
+ mlx->param == NCSI_OEM_MLX_CMD_GMA_PARAM)
+ return ncsi_rsp_handler_oem_mlx_gma(nr);
+ return 0;
+}
+
/* Response handler for Broadcom command Get Mac Address */
static int ncsi_rsp_handler_oem_bcm_gma(struct ncsi_request *nr)
{
@@ -655,7 +694,7 @@ static struct ncsi_rsp_oem_handler {
unsigned int mfr_id;
int (*handler)(struct ncsi_request *nr);
} ncsi_rsp_oem_handlers[] = {
- { NCSI_OEM_MFR_MLX_ID, NULL },
+ { NCSI_OEM_MFR_MLX_ID, ncsi_rsp_handler_oem_mlx },
{ NCSI_OEM_MFR_BCM_ID, ncsi_rsp_handler_oem_bcm }
};
--
2.17.1
^ permalink raw reply related
* RE: [PATCH net-next 2/4] net/hyperv: use skb_vlan_tag_*() helpers
From: Haiyang Zhang @ 2018-11-20 20:37 UTC (permalink / raw)
To: Michał Mirosław, netdev@vger.kernel.org
Cc: KY Srinivasan, Stephen Hemminger, devel@linuxdriverproject.org,
Ajit Khaparde, Leon Romanovsky, linux-rdma@vger.kernel.org,
Saeed Mahameed, Sathya Perla, Somnath Kotur,
Sriharsha Basavapatna
In-Reply-To: <61f737ec45c9905d5c86fbe8492eaa604bf6549f.1542716156.git.mirq-linux@rere.qmqm.pl>
> -----Original Message-----
> From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Sent: Tuesday, November 20, 2018 7:21 AM
> To: netdev@vger.kernel.org
> Cc: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> <haiyangz@microsoft.com>; Stephen Hemminger
> <sthemmin@microsoft.com>; devel@linuxdriverproject.org; Ajit Khaparde
> <ajit.khaparde@broadcom.com>; Leon Romanovsky <leon@kernel.org>;
> linux-rdma@vger.kernel.org; Saeed Mahameed <saeedm@mellanox.com>;
> Sathya Perla <sathya.perla@broadcom.com>; Somnath Kotur
> <somnath.kotur@broadcom.com>; Sriharsha Basavapatna
> <sriharsha.basavapatna@broadcom.com>
> Subject: [PATCH net-next 2/4] net/hyperv: use skb_vlan_tag_*() helpers
>
> Replace open-coded bitfield manipulation with skb_vlan_tag_*() helpers.
> This also enables correctly passing of VLAN.CFI bit.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> ---
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Thanks.
^ permalink raw reply
* Re: [PATCH v5 bpf-next 05/13] bpf: Introduce bpf_func_info
From: kbuild test robot @ 2018-11-20 20:41 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: kbuild-all, netdev, Alexei Starovoitov, Daniel Borkmann,
kernel-team, Yonghong Song
In-Reply-To: <20181119232911.145454-1-kafai@fb.com>
[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]
Hi Yonghong,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/0day-ci/linux/commits/Martin-KaFai-Lau/bpf-Add-btf-func-info-support/20181120-181333
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: i386-randconfig-s0-11191736 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
kernel/bpf/core.o: In function `bpf_get_prog_name':
>> kernel/bpf/core.c:414: undefined reference to `btf_type_by_id'
>> kernel/bpf/core.c:415: undefined reference to `btf_name_by_offset'
vim +414 kernel/bpf/core.c
391
392 static void bpf_get_prog_name(const struct bpf_prog *prog, char *sym)
393 {
394 const char *end = sym + KSYM_NAME_LEN;
395 const struct btf_type *type;
396 const char *func_name;
397
398 BUILD_BUG_ON(sizeof("bpf_prog_") +
399 sizeof(prog->tag) * 2 +
400 /* name has been null terminated.
401 * We should need +1 for the '_' preceding
402 * the name. However, the null character
403 * is double counted between the name and the
404 * sizeof("bpf_prog_") above, so we omit
405 * the +1 here.
406 */
407 sizeof(prog->aux->name) > KSYM_NAME_LEN);
408
409 sym += snprintf(sym, KSYM_NAME_LEN, "bpf_prog_");
410 sym = bin2hex(sym, prog->tag, sizeof(prog->tag));
411
412 /* prog->aux->name will be ignored if full btf name is available */
413 if (prog->aux->btf) {
> 414 type = btf_type_by_id(prog->aux->btf, prog->aux->type_id);
> 415 func_name = btf_name_by_offset(prog->aux->btf, type->name_off);
416 snprintf(sym, (size_t)(end - sym), "_%s", func_name);
417 return;
418 }
419
420 if (prog->aux->name[0])
421 snprintf(sym, (size_t)(end - sym), "_%s", prog->aux->name);
422 else
423 *sym = 0;
424 }
425
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 36733 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next] libbpf: make sure bpf headers are c++ include-able
From: Y Song @ 2018-11-20 21:00 UTC (permalink / raw)
To: Stanislav Fomichev; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20181120181440.10346-1-sdf@google.com>
On Tue, Nov 20, 2018 at 10:19 AM Stanislav Fomichev <sdf@google.com> wrote:
>
> Wrap headers in extern "C", to turn off C++ mangling.
> This simplifies including libbpf in c++ and linking against it.
>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
> ---
> tools/lib/bpf/bpf.h | 9 +++++++++
> tools/lib/bpf/libbpf.h | 9 +++++++++
Do you want to add tools/lib/bpf/btf.h as well? it has some functions
which could be used outside libbpf as well.
> 2 files changed, 18 insertions(+)
>
> diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> index 26a51538213c..9ea3aec82d8a 100644
> --- a/tools/lib/bpf/bpf.h
> +++ b/tools/lib/bpf/bpf.h
> @@ -27,6 +27,10 @@
> #include <stdbool.h>
> #include <stddef.h>
>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
Some (but not all) __cplusplus extern wrappers wraps standard include as well
like "#include <stdbool.h>", "#include <stddef.h>". probably does not
matter here
since they may not have function prototype. But just want to point it out so you
are aware of this and may double check.
> +
> #ifndef LIBBPF_API
> #define LIBBPF_API __attribute__((visibility("default")))
> #endif
> @@ -128,4 +132,9 @@ LIBBPF_API int bpf_load_btf(void *btf, __u32 btf_size, char *log_buf,
> LIBBPF_API int bpf_task_fd_query(int pid, int fd, __u32 flags, char *buf,
> __u32 *buf_len, __u32 *prog_id, __u32 *fd_type,
> __u64 *probe_offset, __u64 *probe_addr);
> +
> +#ifdef __cplusplus
> +} /* extern "C" */
> +#endif
> +
> #endif /* __LIBBPF_BPF_H */
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index b1686a787102..74e57e041705 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -16,6 +16,10 @@
> #include <sys/types.h> // for size_t
> #include <linux/bpf.h>
>
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> #ifndef LIBBPF_API
> #define LIBBPF_API __attribute__((visibility("default")))
> #endif
> @@ -335,4 +339,9 @@ int libbpf_nl_get_qdisc(int sock, unsigned int nl_pid, int ifindex,
> libbpf_dump_nlmsg_t dump_qdisc_nlmsg, void *cookie);
> int libbpf_nl_get_filter(int sock, unsigned int nl_pid, int ifindex, int handle,
> libbpf_dump_nlmsg_t dump_filter_nlmsg, void *cookie);
> +
> +#ifdef __cplusplus
> +} /* extern "C" */
> +#endif
> +
> #endif /* __LIBBPF_LIBBPF_H */
> --
> 2.19.1.1215.g8438c0b245-goog
>
^ permalink raw reply
* Re: [PATCH v3 4/5] phy: mvebu-cp110-comphy: convert to use eth phy mode and submode
From: Kishon Vijay Abraham I @ 2018-11-21 7:38 UTC (permalink / raw)
To: Grygorii Strashko, David S. Miller, Antoine Tenart,
Quentin Schulz, Russell King - ARM Linux, Maxime Chevallier
Cc: Alexandre Belloni, Manu Gautam, Tony Lindgren, netdev,
Sekhar Nori, linux-kernel, Maxime Ripard, Chen-Yu Tsai,
Chunfeng Yun, linux-mediatek, Vivek Gautam, Carlo Caione,
linux-amlogic, linux-arm-kernel, Matthias Brugger
In-Reply-To: <20181120012424.11802-5-grygorii.strashko@ti.com>
Antoine,
On 20/11/18 6:54 AM, Grygorii Strashko wrote:
> Convert mvebu-cp110-comphy PHY driver to use recently introduced
> PHY_MODE_ETHERNET and phy_set_mode_ext().
Care to give ACK for this patch?
Thanks
kishon
>
> Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
> Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>
> Cc: Antoine Tenart <antoine.tenart@free-electrons.com>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 19 +-----
> drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 90 ++++++++++++++-----------
> 2 files changed, 53 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 7a37a37..731793a 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -1165,28 +1165,13 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
> */
> static int mvpp22_comphy_init(struct mvpp2_port *port)
> {
> - enum phy_mode mode;
> int ret;
>
> if (!port->comphy)
> return 0;
>
> - switch (port->phy_interface) {
> - case PHY_INTERFACE_MODE_SGMII:
> - case PHY_INTERFACE_MODE_1000BASEX:
> - mode = PHY_MODE_SGMII;
> - break;
> - case PHY_INTERFACE_MODE_2500BASEX:
> - mode = PHY_MODE_2500SGMII;
> - break;
> - case PHY_INTERFACE_MODE_10GKR:
> - mode = PHY_MODE_10GKR;
> - break;
> - default:
> - return -EINVAL;
> - }
> -
> - ret = phy_set_mode(port->comphy, mode);
> + ret = phy_set_mode_ext(port->comphy, PHY_MODE_ETHERNET,
> + port->phy_interface);
> if (ret)
> return ret;
>
> diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> index 79b52c3..2b4462a 100644
> --- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> +++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> @@ -9,6 +9,7 @@
> #include <linux/iopoll.h>
> #include <linux/mfd/syscon.h>
> #include <linux/module.h>
> +#include <linux/phy.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> #include <linux/regmap.h>
> @@ -116,41 +117,43 @@
>
> struct mvebu_comhy_conf {
> enum phy_mode mode;
> + int submode;
> unsigned lane;
> unsigned port;
> u32 mux;
> };
>
> -#define MVEBU_COMPHY_CONF(_lane, _port, _mode, _mux) \
> +#define MVEBU_COMPHY_CONF(_lane, _port, _submode, _mux) \
> { \
> .lane = _lane, \
> .port = _port, \
> - .mode = _mode, \
> + .mode = PHY_MODE_ETHERNET, \
> + .submode = _submode, \
> .mux = _mux, \
> }
>
> static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
> /* lane 0 */
> - MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
> - MVEBU_COMPHY_CONF(0, 1, PHY_MODE_2500SGMII, 0x1),
> + MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_SGMII, 0x1),
> + MVEBU_COMPHY_CONF(0, 1, PHY_INTERFACE_MODE_2500BASEX, 0x1),
> /* lane 1 */
> - MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
> - MVEBU_COMPHY_CONF(1, 2, PHY_MODE_2500SGMII, 0x1),
> + MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_SGMII, 0x1),
> + MVEBU_COMPHY_CONF(1, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1),
> /* lane 2 */
> - MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
> - MVEBU_COMPHY_CONF(2, 0, PHY_MODE_2500SGMII, 0x1),
> - MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
> + MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_SGMII, 0x1),
> + MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_2500BASEX, 0x1),
> + MVEBU_COMPHY_CONF(2, 0, PHY_INTERFACE_MODE_10GKR, 0x1),
> /* lane 3 */
> - MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
> - MVEBU_COMPHY_CONF(3, 1, PHY_MODE_2500SGMII, 0x2),
> + MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_SGMII, 0x2),
> + MVEBU_COMPHY_CONF(3, 1, PHY_INTERFACE_MODE_2500BASEX, 0x2),
> /* lane 4 */
> - MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
> - MVEBU_COMPHY_CONF(4, 0, PHY_MODE_2500SGMII, 0x2),
> - MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
> - MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
> + MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_SGMII, 0x2),
> + MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_2500BASEX, 0x2),
> + MVEBU_COMPHY_CONF(4, 0, PHY_INTERFACE_MODE_10GKR, 0x2),
> + MVEBU_COMPHY_CONF(4, 1, PHY_INTERFACE_MODE_SGMII, 0x1),
> /* lane 5 */
> - MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
> - MVEBU_COMPHY_CONF(5, 2, PHY_MODE_2500SGMII, 0x1),
> + MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_SGMII, 0x1),
> + MVEBU_COMPHY_CONF(5, 2, PHY_INTERFACE_MODE_2500BASEX, 0x1),
> };
>
> struct mvebu_comphy_priv {
> @@ -163,10 +166,12 @@ struct mvebu_comphy_lane {
> struct mvebu_comphy_priv *priv;
> unsigned id;
> enum phy_mode mode;
> + int submode;
> int port;
> };
>
> -static int mvebu_comphy_get_mux(int lane, int port, enum phy_mode mode)
> +static int mvebu_comphy_get_mux(int lane, int port,
> + enum phy_mode mode, int submode)
> {
> int i, n = ARRAY_SIZE(mvebu_comphy_cp110_modes);
>
> @@ -177,7 +182,8 @@ static int mvebu_comphy_get_mux(int lane, int port, enum phy_mode mode)
> for (i = 0; i < n; i++) {
> if (mvebu_comphy_cp110_modes[i].lane == lane &&
> mvebu_comphy_cp110_modes[i].port == port &&
> - mvebu_comphy_cp110_modes[i].mode == mode)
> + mvebu_comphy_cp110_modes[i].mode == mode &&
> + mvebu_comphy_cp110_modes[i].submode == submode)
> break;
> }
>
> @@ -187,8 +193,7 @@ static int mvebu_comphy_get_mux(int lane, int port, enum phy_mode mode)
> return mvebu_comphy_cp110_modes[i].mux;
> }
>
> -static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
> - enum phy_mode mode)
> +static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane)
> {
> struct mvebu_comphy_priv *priv = lane->priv;
> u32 val;
> @@ -206,14 +211,14 @@ static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
> MVEBU_COMPHY_SERDES_CFG0_HALF_BUS |
> MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xf) |
> MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xf));
> - if (mode == PHY_MODE_10GKR)
> + if (lane->submode == PHY_INTERFACE_MODE_10GKR)
> val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xe) |
> MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xe);
> - else if (mode == PHY_MODE_2500SGMII)
> + else if (lane->submode == PHY_INTERFACE_MODE_2500BASEX)
> val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x8) |
> MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x8) |
> MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
> - else if (mode == PHY_MODE_SGMII)
> + else if (lane->submode == PHY_INTERFACE_MODE_SGMII)
> val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x6) |
> MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x6) |
> MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
> @@ -243,7 +248,7 @@ static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
> /* refclk selection */
> val = readl(priv->base + MVEBU_COMPHY_MISC_CTRL0(lane->id));
> val &= ~MVEBU_COMPHY_MISC_CTRL0_REFCLK_SEL;
> - if (mode == PHY_MODE_10GKR)
> + if (lane->submode == PHY_INTERFACE_MODE_10GKR)
> val |= MVEBU_COMPHY_MISC_CTRL0_ICP_FORCE;
> writel(val, priv->base + MVEBU_COMPHY_MISC_CTRL0(lane->id));
>
> @@ -261,8 +266,7 @@ static void mvebu_comphy_ethernet_init_reset(struct mvebu_comphy_lane *lane,
> writel(val, priv->base + MVEBU_COMPHY_LOOPBACK(lane->id));
> }
>
> -static int mvebu_comphy_init_plls(struct mvebu_comphy_lane *lane,
> - enum phy_mode mode)
> +static int mvebu_comphy_init_plls(struct mvebu_comphy_lane *lane)
> {
> struct mvebu_comphy_priv *priv = lane->priv;
> u32 val;
> @@ -303,13 +307,13 @@ static int mvebu_comphy_init_plls(struct mvebu_comphy_lane *lane,
> return 0;
> }
>
> -static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
> +static int mvebu_comphy_set_mode_sgmii(struct phy *phy)
> {
> struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
> struct mvebu_comphy_priv *priv = lane->priv;
> u32 val;
>
> - mvebu_comphy_ethernet_init_reset(lane, mode);
> + mvebu_comphy_ethernet_init_reset(lane);
>
> val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
> val &= ~MVEBU_COMPHY_RX_CTRL1_CLK8T_EN;
> @@ -330,7 +334,7 @@ static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
> val |= MVEBU_COMPHY_GEN1_S0_TX_EMPH(0x1);
> writel(val, priv->base + MVEBU_COMPHY_GEN1_S0(lane->id));
>
> - return mvebu_comphy_init_plls(lane, PHY_MODE_SGMII);
> + return mvebu_comphy_init_plls(lane);
> }
>
> static int mvebu_comphy_set_mode_10gkr(struct phy *phy)
> @@ -339,7 +343,7 @@ static int mvebu_comphy_set_mode_10gkr(struct phy *phy)
> struct mvebu_comphy_priv *priv = lane->priv;
> u32 val;
>
> - mvebu_comphy_ethernet_init_reset(lane, PHY_MODE_10GKR);
> + mvebu_comphy_ethernet_init_reset(lane);
>
> val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
> val |= MVEBU_COMPHY_RX_CTRL1_RXCLK2X_SEL |
> @@ -469,7 +473,7 @@ static int mvebu_comphy_set_mode_10gkr(struct phy *phy)
> val |= MVEBU_COMPHY_EXT_SELV_RX_SAMPL(0x1a);
> writel(val, priv->base + MVEBU_COMPHY_EXT_SELV(lane->id));
>
> - return mvebu_comphy_init_plls(lane, PHY_MODE_10GKR);
> + return mvebu_comphy_init_plls(lane);
> }
>
> static int mvebu_comphy_power_on(struct phy *phy)
> @@ -479,7 +483,8 @@ static int mvebu_comphy_power_on(struct phy *phy)
> int ret, mux;
> u32 val;
>
> - mux = mvebu_comphy_get_mux(lane->id, lane->port, lane->mode);
> + mux = mvebu_comphy_get_mux(lane->id, lane->port,
> + lane->mode, lane->submode);
> if (mux < 0)
> return -ENOTSUPP;
>
> @@ -492,12 +497,12 @@ static int mvebu_comphy_power_on(struct phy *phy)
> val |= mux << MVEBU_COMPHY_SELECTOR_PHY(lane->id);
> regmap_write(priv->regmap, MVEBU_COMPHY_SELECTOR, val);
>
> - switch (lane->mode) {
> - case PHY_MODE_SGMII:
> - case PHY_MODE_2500SGMII:
> - ret = mvebu_comphy_set_mode_sgmii(phy, lane->mode);
> + switch (lane->submode) {
> + case PHY_INTERFACE_MODE_SGMII:
> + case PHY_INTERFACE_MODE_2500BASEX:
> + ret = mvebu_comphy_set_mode_sgmii(phy);
> break;
> - case PHY_MODE_10GKR:
> + case PHY_INTERFACE_MODE_10GKR:
> ret = mvebu_comphy_set_mode_10gkr(phy);
> break;
> default:
> @@ -517,10 +522,17 @@ static int mvebu_comphy_set_mode(struct phy *phy,
> {
> struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
>
> - if (mvebu_comphy_get_mux(lane->id, lane->port, mode) < 0)
> + if (mode != PHY_MODE_ETHERNET)
> + return -EINVAL;
> +
> + if (submode == PHY_INTERFACE_MODE_1000BASEX)
> + submode = PHY_INTERFACE_MODE_SGMII;
> +
> + if (mvebu_comphy_get_mux(lane->id, lane->port, mode, submode) < 0)
> return -EINVAL;
>
> lane->mode = mode;
> + lane->submode = submode;
> return 0;
> }
>
>
^ permalink raw reply
* [PATCH 3/4] tools: bpftool: fix potential NULL pointer dereference in do_load
From: Wen Yang @ 2018-11-21 7:43 UTC (permalink / raw)
To: ast
Cc: daniel, jakub.kicinski, quentin.monnet, jiong.wang, guro,
sandipan, john.fastabend, netdev, linux-kernel, zhong.weidong,
wang.yi59, Wen Yang, Julia Lawall
This patch fixes a possible null pointer dereference in
do_load, detected by the semantic patch
deref_null.cocci, with the following warning:
./tools/bpf/bpftool/prog.c:1021:23-25: ERROR: map_replace is NULL but dereferenced.
The following code has potential null pointer references:
881 map_replace = reallocarray(map_replace, old_map_fds + 1,
882 sizeof(*map_replace));
883 if (!map_replace) {
884 p_err("mem alloc failed");
885 goto err_free_reuse_maps;
886 }
...
1019 err_free_reuse_maps:
1020 for (i = 0; i < old_map_fds; i++)
1021 close(map_replace[i].fd);
1022 free(map_replace);
Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
Reviewed-by: Tan Hu <tan.hu@zte.com.cn>
CC: Julia Lawall <julia.lawall@lip6.fr>
---
tools/bpf/bpftool/prog.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
index 5302ee2..de42187 100644
--- a/tools/bpf/bpftool/prog.c
+++ b/tools/bpf/bpftool/prog.c
@@ -1017,8 +1017,9 @@ static int do_load(int argc, char **argv)
err_close_obj:
bpf_object__close(obj);
err_free_reuse_maps:
- for (i = 0; i < old_map_fds; i++)
- close(map_replace[i].fd);
+ if (map_replace)
+ for (i = 0; i < old_map_fds; i++)
+ close(map_replace[i].fd);
free(map_replace);
return -1;
}
--
2.9.5
^ permalink raw reply related
* [PATCH net v2] net/sched: act_police: fix race condition on state variables
From: Davide Caratti @ 2018-11-20 21:18 UTC (permalink / raw)
To: Eric Dumazet, Jamal Hadi Salim, Cong Wang, Jiri Pirko,
David S. Miller
Cc: netdev, Ivan Vecera
after 'police' configuration parameters were converted to use RCU instead
of spinlock, the state variables used to compute the traffic rate (namely
'tcfp_toks', 'tcfp_ptoks' and 'tcfp_t_c') are erroneously read/updated in
the traffic path without any protection.
Use a dedicated spinlock to avoid race conditions on these variables, and
ensure proper cache-line alignment. In this way, 'police' is still faster
than what we observed when 'tcf_lock' was used in the traffic path _ i.e.
reverting commit 2d550dbad83c ("net/sched: act_police: don't use spinlock
in the data path"). Moreover, we preserve the throughput improvement that
was obtained after 'police' started using per-cpu counters, when 'avrate'
is used instead of 'rate'.
Changes since v1 (thanks to Eric Dumazet):
- call ktime_get_ns() before acquiring the lock in the traffic path
- use a dedicated spinlock instead of tcf_lock
- improve cache-line usage
Fixes: 2d550dbad83c ("net/sched: act_police: don't use spinlock in the data path")
Reported-and-suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
net/sched/act_police.c | 35 +++++++++++++++++++++--------------
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/net/sched/act_police.c b/net/sched/act_police.c
index 052855d47354..ee4665a5a022 100644
--- a/net/sched/act_police.c
+++ b/net/sched/act_police.c
@@ -27,10 +27,7 @@ struct tcf_police_params {
u32 tcfp_ewma_rate;
s64 tcfp_burst;
u32 tcfp_mtu;
- s64 tcfp_toks;
- s64 tcfp_ptoks;
s64 tcfp_mtu_ptoks;
- s64 tcfp_t_c;
struct psched_ratecfg rate;
bool rate_present;
struct psched_ratecfg peak;
@@ -41,6 +38,11 @@ struct tcf_police_params {
struct tcf_police {
struct tc_action common;
struct tcf_police_params __rcu *params;
+
+ spinlock_t tcfp_lock ____cacheline_aligned_in_smp;
+ s64 tcfp_toks;
+ s64 tcfp_ptoks;
+ s64 tcfp_t_c;
};
#define to_police(pc) ((struct tcf_police *)pc)
@@ -186,12 +188,9 @@ static int tcf_police_init(struct net *net, struct nlattr *nla,
}
new->tcfp_burst = PSCHED_TICKS2NS(parm->burst);
- new->tcfp_toks = new->tcfp_burst;
- if (new->peak_present) {
+ if (new->peak_present)
new->tcfp_mtu_ptoks = (s64)psched_l2t_ns(&new->peak,
new->tcfp_mtu);
- new->tcfp_ptoks = new->tcfp_mtu_ptoks;
- }
if (tb[TCA_POLICE_AVRATE])
new->tcfp_ewma_rate = nla_get_u32(tb[TCA_POLICE_AVRATE]);
@@ -207,7 +206,12 @@ static int tcf_police_init(struct net *net, struct nlattr *nla,
}
spin_lock_bh(&police->tcf_lock);
- new->tcfp_t_c = ktime_get_ns();
+ spin_lock_bh(&police->tcfp_lock);
+ police->tcfp_t_c = ktime_get_ns();
+ police->tcfp_toks = new->tcfp_burst;
+ if (new->peak_present)
+ police->tcfp_ptoks = new->tcfp_mtu_ptoks;
+ spin_unlock_bh(&police->tcfp_lock);
police->tcf_action = parm->action;
rcu_swap_protected(police->params,
new,
@@ -257,25 +261,28 @@ static int tcf_police_act(struct sk_buff *skb, const struct tc_action *a,
}
now = ktime_get_ns();
- toks = min_t(s64, now - p->tcfp_t_c, p->tcfp_burst);
+ spin_lock_bh(&police->tcfp_lock);
+ toks = min_t(s64, now - police->tcfp_t_c, p->tcfp_burst);
if (p->peak_present) {
- ptoks = toks + p->tcfp_ptoks;
+ ptoks = toks + police->tcfp_ptoks;
if (ptoks > p->tcfp_mtu_ptoks)
ptoks = p->tcfp_mtu_ptoks;
ptoks -= (s64)psched_l2t_ns(&p->peak,
qdisc_pkt_len(skb));
}
- toks += p->tcfp_toks;
+ toks += police->tcfp_toks;
if (toks > p->tcfp_burst)
toks = p->tcfp_burst;
toks -= (s64)psched_l2t_ns(&p->rate, qdisc_pkt_len(skb));
if ((toks|ptoks) >= 0) {
- p->tcfp_t_c = now;
- p->tcfp_toks = toks;
- p->tcfp_ptoks = ptoks;
+ police->tcfp_t_c = now;
+ police->tcfp_toks = toks;
+ police->tcfp_ptoks = ptoks;
+ spin_unlock_bh(&police->tcfp_lock);
ret = p->tcfp_result;
goto inc_drops;
}
+ spin_unlock_bh(&police->tcfp_lock);
}
inc_overlimits:
--
2.19.1
^ permalink raw reply related
* Re: [PATCH bpf-next] bpf: libbpf: retry program creation without the name
From: Stanislav Fomichev @ 2018-11-20 21:19 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: Stanislav Fomichev, netdev, daniel, ast, vladum
In-Reply-To: <20181120195121.td3bugcegudhh2ou@ast-mbp.dhcp.thefacebook.com>
On 11/20, Alexei Starovoitov wrote:
> On Mon, Nov 19, 2018 at 04:46:25PM -0800, Stanislav Fomichev wrote:
> > [Recent commit 23499442c319 ("bpf: libbpf: retry map creation without
> > the name") fixed this issue for maps, let's do the same for programs.]
> >
> > Since commit 88cda1c9da02 ("bpf: libbpf: Provide basic API support
> > to specify BPF obj name"), libbpf unconditionally sets bpf_attr->name
> > for programs. Pre v4.14 kernels don't know about programs names and
> > return an error about unexpected non-zero data. Retry sys_bpf without
> > a program name to cover older kernels.
> >
> > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > ---
> > tools/lib/bpf/bpf.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> > index 961e1b9fc592..cbe9d757c646 100644
> > --- a/tools/lib/bpf/bpf.c
> > +++ b/tools/lib/bpf/bpf.c
> > @@ -212,6 +212,16 @@ int bpf_load_program_xattr(const struct bpf_load_program_attr *load_attr,
> > if (fd >= 0 || !log_buf || !log_buf_sz)
> > return fd;
> >
> > + if (fd < 0 && errno == E2BIG && load_attr->name) {
> > + /* Retry the same syscall, but without the name.
> > + * Pre v4.14 kernels don't support prog names.
> > + */
>
> I'm afraid that will put unnecessary stress on the kernel.
> This check needs to be tighter.
> Like E2BIG and anything in the log_buf probably means that
> E2BIG came from the verifier and nothing to do with prog_name.
> Asking kernel to repeat is an unnecessary work.
>
> In general we need to think beyond this single prog_name field.
> There are bunch of other fields in bpf_load_program_xattr() and older kernels
> won't support them. Are we going to zero them out one by one
> and retry? I don't think that would be practical.
I general, we don't want to zero anything out. However,
for this particular problem the rationale is the following:
In commit 88cda1c9da02 we started unconditionally setting {prog,map}->name
from the 'higher' libbpfc layer which breaks users on the older kernels.
> Also libbpf silently ignoring prog_name is not great for debugging.
> A warning is needed.
> But it cannot be done out of lib/bpf/bpf.c, since it's a set of syscall
> wrappers.
> Imo such "old kernel -> lets retry" feature should probably be done
> at lib/bpf/libbpf.c level. inside load_program().
For maps bpftools calls bpf_create_map_xattr directly, that's why
for maps I did the retry on the lower level (and why for programs I initially
thought about doing the same). However, in this case maybe asking
user to omit 'name' argument might be a better option.
For program names, I agree, we might think about doing it on the higher
level (although I'm not sure whether we want to have different API
expectations, i.e. bpf_create_map_xattr ignoring the name and
bpf_load_program_xattr not ignoring the name).
So given that rationale above, what do you think is the best way to
move forward?
1. Same patch, but tighten the retry check inside bpf_load_program_xattr ?
2. Move this retry logic into load_program and have different handling
for bpf_create_map_xattr vs bpf_load_program_xattr ?
3. Do 2 and move the retry check for maps from bpf_create_map_xattr
into bpf_object__create_maps ?
(I'm slightly leaning towards #3)
^ permalink raw reply
* Re: [PATCH v3 4/5] phy: mvebu-cp110-comphy: convert to use eth phy mode and submode
From: Quentin Schulz @ 2018-11-21 7:52 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Grygorii Strashko, David S. Miller, Antoine Tenart,
Russell King - ARM Linux, Maxime Chevallier, netdev, Sekhar Nori,
linux-kernel, linux-arm-kernel, Tony Lindgren, linux-amlogic,
linux-mediatek, Alexandre Belloni, Vivek Gautam, Maxime Ripard,
Chen-Yu Tsai, Carlo Caione, Chunfeng Yun, Matthias Brugger,
Manu Gautam <mg
In-Reply-To: <d80901b2-a38a-7abf-23b2-c2b0c84ff321@ti.com>
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
Hi Kishon,
On Wed, Nov 21, 2018 at 01:08:42PM +0530, Kishon Vijay Abraham I wrote:
> Antoine,
>
> On 20/11/18 6:54 AM, Grygorii Strashko wrote:
> > Convert mvebu-cp110-comphy PHY driver to use recently introduced
> > PHY_MODE_ETHERNET and phy_set_mode_ext().
>
> Care to give ACK for this patch?
>
Acked-by Antoine and Tested-by Maxime given in v2:
https://patchwork.kernel.org/patch/10676749/
Quentin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next] libbpf: make sure bpf headers are c++ include-able
From: Stanislav Fomichev @ 2018-11-20 21:24 UTC (permalink / raw)
To: Y Song; +Cc: Stanislav Fomichev, netdev, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <CAH3MdRXw+XCtvUyt_5jxBBHMD7HYeB1xHanmSxUjYioFOWhiOQ@mail.gmail.com>
On 11/20, Y Song wrote:
> On Tue, Nov 20, 2018 at 10:19 AM Stanislav Fomichev <sdf@google.com> wrote:
> >
> > Wrap headers in extern "C", to turn off C++ mangling.
> > This simplifies including libbpf in c++ and linking against it.
> >
> > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > ---
> > tools/lib/bpf/bpf.h | 9 +++++++++
> > tools/lib/bpf/libbpf.h | 9 +++++++++
>
> Do you want to add tools/lib/bpf/btf.h as well? it has some functions
> which could be used outside libbpf as well.
Sure, I can do that in v2.
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
> > index 26a51538213c..9ea3aec82d8a 100644
> > --- a/tools/lib/bpf/bpf.h
> > +++ b/tools/lib/bpf/bpf.h
> > @@ -27,6 +27,10 @@
> > #include <stdbool.h>
> > #include <stddef.h>
> >
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
>
> Some (but not all) __cplusplus extern wrappers wraps standard include as well
> like "#include <stdbool.h>", "#include <stddef.h>". probably does not
> matter here
> since they may not have function prototype. But just want to point it out so you
> are aware of this and may double check.
Standard headers should be safe, they are usually wrapped into
__BEGIN_DECLS/__END_DECLS (which is extern "C" {}). For <linux/bpf.h>
I don't think we need an extern, because it only defines enums/structs
and not something we can link against (global vars/functions).
> > +
> > #ifndef LIBBPF_API
> > #define LIBBPF_API __attribute__((visibility("default")))
> > #endif
> > @@ -128,4 +132,9 @@ LIBBPF_API int bpf_load_btf(void *btf, __u32 btf_size, char *log_buf,
> > LIBBPF_API int bpf_task_fd_query(int pid, int fd, __u32 flags, char *buf,
> > __u32 *buf_len, __u32 *prog_id, __u32 *fd_type,
> > __u64 *probe_offset, __u64 *probe_addr);
> > +
> > +#ifdef __cplusplus
> > +} /* extern "C" */
> > +#endif
> > +
> > #endif /* __LIBBPF_BPF_H */
> > diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> > index b1686a787102..74e57e041705 100644
> > --- a/tools/lib/bpf/libbpf.h
> > +++ b/tools/lib/bpf/libbpf.h
> > @@ -16,6 +16,10 @@
> > #include <sys/types.h> // for size_t
> > #include <linux/bpf.h>
> >
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > #ifndef LIBBPF_API
> > #define LIBBPF_API __attribute__((visibility("default")))
> > #endif
> > @@ -335,4 +339,9 @@ int libbpf_nl_get_qdisc(int sock, unsigned int nl_pid, int ifindex,
> > libbpf_dump_nlmsg_t dump_qdisc_nlmsg, void *cookie);
> > int libbpf_nl_get_filter(int sock, unsigned int nl_pid, int ifindex, int handle,
> > libbpf_dump_nlmsg_t dump_filter_nlmsg, void *cookie);
> > +
> > +#ifdef __cplusplus
> > +} /* extern "C" */
> > +#endif
> > +
> > #endif /* __LIBBPF_LIBBPF_H */
> > --
> > 2.19.1.1215.g8438c0b245-goog
> >
^ permalink raw reply
* Re: [PATCH v3 4/5] phy: mvebu-cp110-comphy: convert to use eth phy mode and submode
From: Antoine Tenart @ 2018-11-21 7:58 UTC (permalink / raw)
To: Quentin Schulz
Cc: Kishon Vijay Abraham I, Grygorii Strashko, David S. Miller,
Antoine Tenart, Russell King - ARM Linux, Maxime Chevallier,
netdev, Sekhar Nori, linux-kernel, linux-arm-kernel,
Tony Lindgren, linux-amlogic, linux-mediatek, Alexandre Belloni,
Vivek Gautam, Maxime Ripard, Chen-Yu Tsai, Carlo Caione,
Chunfeng Yun, Matthias Brugger <
In-Reply-To: <20181121075220.z6smcpk3y7vab7ix@qschulz>
Hi Quentin,
On Wed, Nov 21, 2018 at 08:52:20AM +0100, Quentin Schulz wrote:
> On Wed, Nov 21, 2018 at 01:08:42PM +0530, Kishon Vijay Abraham I wrote:
> >
> > On 20/11/18 6:54 AM, Grygorii Strashko wrote:
> > > Convert mvebu-cp110-comphy PHY driver to use recently introduced
> > > PHY_MODE_ETHERNET and phy_set_mode_ext().
> >
> > Care to give ACK for this patch?
> >
>
> Acked-by Antoine and Tested-by Maxime given in v2:
> https://patchwork.kernel.org/patch/10676749/
The Acks were removed from v3 due to changes in the patches.
Thanks,
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [net] xfrm_user: use xfrm_state_put to free xfrm_state_alloc return value
From: Herbert Xu @ 2018-11-21 8:00 UTC (permalink / raw)
To: Pan Bian
Cc: Steffen Klassert, David S. Miller, netdev, linux-kernel, Pan Bian,
Mathias Krause
In-Reply-To: <1542783468-67482-1-git-send-email-bianpan2016@163.com>
On Wed, Nov 21, 2018 at 02:57:48PM +0800, Pan Bian wrote:
> From: Pan Bian <bianpan2013@163.com>
>
> The memory chunk allocated by xfrm_state_alloc() should be released with
> xfrm_state_put(), not kfree.
>
> Signed-off-by: Pan Bian <bianpan2013@163.com>
This bug was introduced by
commit 565f0fa902b64020d5d147ff1708567e9e0b6e49
Author: Mathias Krause <minipli@googlemail.com>
Date: Thu May 3 10:55:07 2018 +0200
While using xfrm_state_put may work it's certainly not the designed
to do this. We should instead export a function that calls
kmem_cache_free on xfrm_state directly and use that here.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH net-next 00/16] mlxsw: Add VxLAN learning support
From: Ido Schimmel @ 2018-11-21 8:02 UTC (permalink / raw)
To: netdev@vger.kernel.org, bridge@lists.linux-foundation.org
Cc: ivecera@redhat.com, Ido Schimmel, mlxsw,
nikolay@cumulusnetworks.com, roopa@cumulusnetworks.com,
Jiri Pirko, Petr Machata, davem@davemloft.net
This patchset adds VxLAN learning support in the mlxsw driver.
The first five patches from Petr add the required switchdev APIs which
allow device drivers to notify the VxLAN driver about learned / aged-out
FDB entries.
First in patch #1, an unnecessary argument is dropped from
__vxlan_fdb_delete().
In patches #2-#4, the VxLAN FDB handling code is extended to make
sending the switchdev events configurable; to mark user-added entries as
such; and to make sure HW-learned FDB entries do not take over
user-added ones.
Finally in patch #5, the necessary switchdev notifications are added and
handled by VxLAN, similarly to how this is handled in the bridge driver.
Patch #6 allows changing of the VxLAN's device ageing time since it is
useful for the selftest in the last patch.
Patch #7 adds support for querying bridge port flags of a given
netdevice, as a new entry should not be learned and notified to the
bridge driver in case learning is disabled on the bridge port.
Next patches gradually add learning support in mlxsw.
The last patch adds a new test case for VxLAN learning.
Ido Schimmel (11):
vxlan: Allow changing ageing time
bridge: Allow querying bridge port flags
mlxsw: reg: Add definition of unicast tunnel record for SFN register
mlxsw: spectrum_fid: Store ifindex of NVE device in FID
mlxsw: spectrum_fid: Allow FID lookup by its index
mlxsw: spectrum_nve: Add API to resolve learned IP addresses
mlxsw: spectrum_switchdev: Process learned VxLAN FDB entries
mlxsw: spectrum_switchdev: Allow deletion of learned FDB entries
mlxsw: spectrum_nve: Allow VxLAN learning
selftests: mlxsw: Consider VxLAN learning enabled as valid
selftests: forwarding: vxlan_bridge_1d: Add learning test
Petr Machata (5):
vxlan: __vxlan_fdb_delete(): Drop unused argument vid
vxlan: vxlan_fdb_notify(): Make switchdev notification configurable
vxlan: Mark user-added FDB entries
vxlan: Don't override user-added entries with ext-learned ones
vxlan: Add hardware FDB learning
drivers/net/ethernet/mellanox/mlxsw/reg.h | 64 ++++++
.../net/ethernet/mellanox/mlxsw/spectrum.h | 8 +-
.../ethernet/mellanox/mlxsw/spectrum_fid.c | 56 ++++-
.../ethernet/mellanox/mlxsw/spectrum_nve.c | 16 +-
.../mellanox/mlxsw/spectrum_nve_vxlan.c | 8 +-
.../mellanox/mlxsw/spectrum_switchdev.c | 206 ++++++++++++++++--
drivers/net/vxlan.c | 192 ++++++++++++----
include/linux/if_bridge.h | 6 +
include/net/switchdev.h | 2 +
include/net/vxlan.h | 1 +
net/bridge/br_if.c | 12 +
.../selftests/drivers/net/mlxsw/vxlan.sh | 2 +-
.../net/forwarding/vxlan_bridge_1d.sh | 108 +++++++++
13 files changed, 606 insertions(+), 75 deletions(-)
--
2.19.1
^ permalink raw reply
* [PATCH bpf-next v2] libbpf: make sure bpf headers are c++ include-able
From: Stanislav Fomichev @ 2018-11-20 21:37 UTC (permalink / raw)
To: netdev, ast, daniel, ys114321; +Cc: Stanislav Fomichev
In-Reply-To: <20181120212407.7fq5ails7atxby3f@mini-arch.hsd1.ca.comcast.net>
Wrap headers in extern "C", to turn off C++ mangling.
This simplifies including libbpf in c++ and linking against it.
v2 changes:
* do the same for btf.h
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/lib/bpf/bpf.h | 9 +++++++++
tools/lib/bpf/btf.h | 8 ++++++++
tools/lib/bpf/libbpf.h | 9 +++++++++
3 files changed, 26 insertions(+)
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 26a51538213c..9ea3aec82d8a 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -27,6 +27,10 @@
#include <stdbool.h>
#include <stddef.h>
+#ifdef __cplusplus
+extern "C" {
+#endif
+
#ifndef LIBBPF_API
#define LIBBPF_API __attribute__((visibility("default")))
#endif
@@ -128,4 +132,9 @@ LIBBPF_API int bpf_load_btf(void *btf, __u32 btf_size, char *log_buf,
LIBBPF_API int bpf_task_fd_query(int pid, int fd, __u32 flags, char *buf,
__u32 *buf_len, __u32 *prog_id, __u32 *fd_type,
__u64 *probe_offset, __u64 *probe_addr);
+
+#ifdef __cplusplus
+} /* extern "C" */
+#endif
+
#endif /* __LIBBPF_BPF_H */
diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
index b77e7080f7e7..5f3d7de850fc 100644
--- a/tools/lib/bpf/btf.h
+++ b/tools/lib/bpf/btf.h
@@ -6,6 +6,10 @@
#include <linux/types.h>
+#ifdef __cplusplus
+extern "C" {
+#endif
+
#ifndef LIBBPF_API
#define LIBBPF_API __attribute__((visibility("default")))
#endif
@@ -29,4 +33,8 @@ LIBBPF_API int btf__resolve_type(const struct btf *btf, __u32 type_id);
LIBBPF_API int btf__fd(const struct btf *btf);
LIBBPF_API const char *btf__name_by_offset(const struct btf *btf, __u32 offset);
+#ifdef __cplusplus
+} /* extern "C" */
+#endif
+
#endif /* __LIBBPF_BTF_H */
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index b1686a787102..74e57e041705 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -16,6 +16,10 @@
#include <sys/types.h> // for size_t
#include <linux/bpf.h>
+#ifdef __cplusplus
+extern "C" {
+#endif
+
#ifndef LIBBPF_API
#define LIBBPF_API __attribute__((visibility("default")))
#endif
@@ -335,4 +339,9 @@ int libbpf_nl_get_qdisc(int sock, unsigned int nl_pid, int ifindex,
libbpf_dump_nlmsg_t dump_qdisc_nlmsg, void *cookie);
int libbpf_nl_get_filter(int sock, unsigned int nl_pid, int ifindex, int handle,
libbpf_dump_nlmsg_t dump_filter_nlmsg, void *cookie);
+
+#ifdef __cplusplus
+} /* extern "C" */
+#endif
+
#endif /* __LIBBPF_LIBBPF_H */
--
2.19.1.1215.g8438c0b245-goog
^ permalink raw reply related
* RE: [PATCH v1 net] lan743x: fix return value for lan743x_tx_napi_poll
From: Bryan.Whitehead @ 2018-11-20 21:39 UTC (permalink / raw)
To: andrew; +Cc: davem, netdev, UNGLinuxDriver
In-Reply-To: <20181120193054.GE2649@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Tuesday, November 20, 2018 2:31 PM
> To: Bryan Whitehead - C21958 <Bryan.Whitehead@microchip.com>
> Cc: davem@davemloft.net; netdev@vger.kernel.org; UNGLinuxDriver
> <UNGLinuxDriver@microchip.com>
> Subject: Re: [PATCH v1 net] lan743x: fix return value for
> lan743x_tx_napi_poll
>
> On Tue, Nov 20, 2018 at 01:26:43PM -0500, Bryan Whitehead wrote:
> > It has been noticed that under stress the lan743x driver will
> > sometimes hang or cause a kernel panic. It has been noticed that
> > returning '0' instead of 'weight' fixes this issue.
> >
> > fixes: rare kernel panic under heavy traffic load.
> > Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
>
> Hi Bryan
>
> This sounds like a band aid over something which is broken, not a real fix.
>
> Can you show us the stack trace from the panic?
>
> Andrew
Andrew,
Admittedly, my knowledge of what the kernel is doing behind the scenes is limited.
But according to documentation found on
https://wiki.linuxfoundation.org/networking/napi
It states the following
"The poll() function may also process TX completions, in which case if it processes
the entire TX ring then it should count that work as the rest of the budget.
Otherwise, TX completions are not counted."
So based on that, the original driver was returning the full budget. But I was having
Issues with it. And the above documentation seems to suggest that I could return 0
As in "not counted" from above.
I tried it, and my lock up issues disappeared.
Regarding the kernel panic stack trace. So far its very hard to replicate that on the
latest kernel. I've seen it more frequently when back porting to older kernels such
as 4.14, and 4.9. This same fix caused those kernel panics to disappear.
Are you interested in seeing a stack dump from older kernels?
In the latest kernel the issue manifests as a kernel message which states
"[ 945.021101] enp48s0: Budget exhausted after napi rescheduled"
I'm not sure what that means. But it does not lock up immediately after seeing that
Message. But it usually locks up with in a minute of seeing that message.
And the sometimes I get the following warning
[ 1240.425020] ------------[ cut here ]------------
[ 1240.426014] NETDEV WATCHDOG: enp0s25 (e1000e): transmit queue 0 timed out
[ 1240.430027] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x1ef/0x200
[ 1240.430027] Modules linked in: lan743x
[ 1240.430027] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G I 4.19.2 #1
[ 1240.430027] Hardware name: Hewlett-Packard HP Compaq dc7900 Convertible Minitower/3032h, BIOS 786G1 v01.16 03/05/2009
[ 1240.430027] RIP: 0010:dev_watchdog+0x1ef/0x200
[ 1240.430027] Code: 00 48 63 4d e0 eb 93 4c 89 e7 c6 05 68 30 b3 00 01 e8 25 3d fd ff 89 d9 48 89 c2 4c 89 e6 48 c7 c7 98 92 48 ab e8 f1 28 87 ff <0f> 0b eb c0 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 48 c7 47 08 00
[ 1240.430027] RSP: 0018:ffff98490be03e90 EFLAGS: 00010282
[ 1240.430027] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 1240.497168] RDX: 0000000000040400 RSI: 00000000000000f6 RDI: 0000000000000300
[ 1240.497168] RBP: ffff984908574440 R08: 0000000000000000 R09: 00000000000003a4
[ 1240.497168] R10: 0000000000000020 R11: ffffffffabc928ed R12: ffff984908574000
[ 1240.497168] R13: 0000000000000000 R14: 0000000000000000 R15: ffff98490be195b0
[ 1240.497168] FS: 0000000000000000(0000) GS:ffff98490be00000(0000) knlGS:0000000000000000
[ 1240.497168] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1240.497168] CR2: 00007f31cd4c0000 CR3: 0000000109bca000 CR4: 00000000000406f0
[ 1240.497168] Call Trace:
[ 1240.497168] <IRQ>
[ 1240.497168] ? qdisc_reset+0xe0/0xe0
[ 1240.497168] call_timer_fn+0x26/0x130
[ 1240.497168] run_timer_softirq+0x1cd/0x400
[ 1240.497168] ? hpet_interrupt_handler+0x10/0x30
[ 1240.497168] __do_softirq+0xed/0x2aa
[ 1240.497168] irq_exit+0xb7/0xc0
[ 1240.497168] do_IRQ+0x45/0xd0
[ 1240.497168] common_interrupt+0xf/0xf
[ 1240.497168] </IRQ>
[ 1240.497168] RIP: 0010:cpuidle_enter_state+0xa6/0x330
[ 1240.497168] Code: 65 8b 3d 1d b0 4d 55 e8 58 6a 95 ff 48 89 c3 66 66 66 66 90 31 ff e8 59 73 95 ff 80 7c 24 0b 00 0f 85 25 02 00 00 fb 4c 29 eb <48> ba cf f7 53 e3 a5 9b c4 20 48 89 d8 48 c1 fb 3f 48 f7 ea b8 ff
[ 1240.497168] RSP: 0018:ffffffffab603e60 EFLAGS: 00000216 ORIG_RAX: ffffffffffffffde
[ 1240.497168] RAX: ffff98490be20a80 RBX: 000000000081035c RCX: 00000120cf178c49
[ 1240.497168] RDX: 00000120cf178ca0 RSI: 00000120cf178ca0 RDI: 0000000000000000
[ 1240.497168] RBP: ffff984908fbd000 R08: fffffffb58ea5f9e R09: 000001208e0b48df
[ 1240.497168] R10: 00000000000018c4 R11: 0000000000002468 R12: 0000000000000002
[ 1240.497168] R13: 00000120ce968944 R14: ffffffffab6a68a0 R15: ffffffffab611740
[ 1240.497168] do_idle+0x1da/0x230
[ 1240.497168] cpu_startup_entry+0x6a/0x70
[ 1240.497168] start_kernel+0x4a2/0x4c2
[ 1240.497168] secondary_startup_64+0xa4/0xb0
[ 1240.497168] ---[ end trace c6f3be34c214db4e ]---
Notice the warning is referring to a different adapter. So I suspect that whatever happened it froze
All network adapters.
If you have suggestions let me know.
Or if you would like to see the kernel panics from older kernels let me know.
Regards,
Bryan
^ permalink raw reply
* Re: [PATCH net v2] net/sched: act_police: fix race condition on state variables
From: Eric Dumazet @ 2018-11-20 21:39 UTC (permalink / raw)
To: dcaratti
Cc: Jamal Hadi Salim, Cong Wang, Jiri Pirko, David Miller, netdev,
ivecera
In-Reply-To: <541a3b91af953326fa8f8fe046f0c284274377ff.1542748323.git.dcaratti@redhat.com>
On Tue, Nov 20, 2018 at 1:19 PM Davide Caratti <dcaratti@redhat.com> wrote:
>
> after 'police' configuration parameters were converted to use RCU instead
> of spinlock, the state variables used to compute the traffic rate (namely
> 'tcfp_toks', 'tcfp_ptoks' and 'tcfp_t_c') are erroneously read/updated in
> the traffic path without any protection.
>
> Use a dedicated spinlock to avoid race conditions on these variables, and
> ensure proper cache-line alignment. In this way, 'police' is still faster
> than what we observed when 'tcf_lock' was used in the traffic path _ i.e.
> reverting commit 2d550dbad83c ("net/sched: act_police: don't use spinlock
> in the data path"). Moreover, we preserve the throughput improvement that
> was obtained after 'police' started using per-cpu counters, when 'avrate'
> is used instead of 'rate'.
>
> Changes since v1 (thanks to Eric Dumazet):
> - call ktime_get_ns() before acquiring the lock in the traffic path
> - use a dedicated spinlock instead of tcf_lock
> - improve cache-line usage
>
> Fixes: 2d550dbad83c ("net/sched: act_police: don't use spinlock in the data path")
> Reported-and-suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
> ---
Thanks a lot for taking care of this.
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [RFC v3 0/3] Add VRF support for VXLAN underlay
From: David Ahern @ 2018-11-20 21:45 UTC (permalink / raw)
To: Alexis Bauvin, roopa; +Cc: netdev, akherbouche
In-Reply-To: <20181120142317.88277-1-abauvin@scaleway.com>
On 11/20/18 7:23 AM, Alexis Bauvin wrote:
> We are trying to isolate the VXLAN traffic from different VMs with VRF as shown
> in the schemas below:
>
> +-------------------------+ +----------------------------+
> | +----------+ | | +------------+ |
> | | | | | | | |
> | | tap-red | | | | tap-blue | |
> | | | | | | | |
> | +----+-----+ | | +-----+------+ |
> | | | | | |
> | | | | | |
> | +----+---+ | | +----+----+ |
> | | | | | | | |
> | | br-red | | | | br-blue | |
> | | | | | | | |
> | +----+---+ | | +----+----+ |
> | | | | | |
> | | | | | |
> | | | | | |
> | +----+--------+ | | +--------------+ |
> | | | | | | | |
> | | vxlan-red | | | | vxlan-blue | |
> | | | | | | | |
> | +------+------+ | | +-------+------+ |
> | | | | | |
> | | VRF | | | VRF |
> | | red | | | blue |
> +-------------------------+ +----------------------------+
Roopa and I were discussing this setup and are puzzled by the VRF
association here. Does br-red and br-blue have an address? The commands
below do not show it and from our perspective seems odd for this
scenario. If it does not have an address, then there is no reason for
the VRF labeling.
Also, it would be good to have a unit test this case. Can you create a
shell script that creates the setup and runs a few tests verifying
connectivity? You can use network namespaces and veth pairs in place of
the VM with a tap device. From there the functionality is the same.
Tests can be initial VRF association for the vxlan lower device,
changing the VRF to another device, and then changing again back to
default VRF - checking proper connectivity for each.
Thanks
^ permalink raw reply
* [PATCH bpf-next] bpf: fix a compilation error when CONFIG_BPF_SYSCALL is not defined
From: Yonghong Song @ 2018-11-20 21:48 UTC (permalink / raw)
To: ast, daniel, netdev, kbuild-all; +Cc: kernel-team, Martin KaFai Lau
Kernel test robot (lkp@intel.com) reports a compilation error at
https://www.spinics.net/lists/netdev/msg534913.html
introduced by commit 838e96904ff3 ("bpf: Introduce bpf_func_info").
If CONFIG_BPF is defined and CONFIG_BPF_SYSCALL is not defined,
the following error will appear:
kernel/bpf/core.c:414: undefined reference to `btf_type_by_id'
kernel/bpf/core.c:415: undefined reference to `btf_name_by_offset'
When CONFIG_BPF_SYSCALL is not defined,
let us define stub inline functions for btf_type_by_id()
and btf_name_by_offset() in include/linux/btf.h.
This way, the compilation failure can be avoided.
Fixes: 838e96904ff3 ("bpf: Introduce bpf_func_info")
Reported-by: kbuild test robot <lkp@intel.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
---
include/linux/btf.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/include/linux/btf.h b/include/linux/btf.h
index 7f2c0a4a45ea..a5e893071861 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -46,7 +46,19 @@ void btf_type_seq_show(const struct btf *btf, u32 type_id, void *obj,
struct seq_file *m);
int btf_get_fd_by_id(u32 id);
u32 btf_id(const struct btf *btf);
+
+#ifdef CONFIG_BPF_SYSCALL
const struct btf_type *btf_type_by_id(const struct btf *btf, u32 type_id);
const char *btf_name_by_offset(const struct btf *btf, u32 offset);
+#else
+const struct btf_type *btf_type_by_id(const struct btf *btf, u32 type_id)
+{
+ return NULL;
+}
+const char *btf_name_by_offset(const struct btf *btf, u32 offset)
+{
+ return NULL;
+}
+#endif
#endif
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v1 net] lan743x: fix return value for lan743x_tx_napi_poll
From: Andrew Lunn @ 2018-11-20 21:55 UTC (permalink / raw)
To: Bryan.Whitehead; +Cc: davem, netdev, UNGLinuxDriver
In-Reply-To: <90A7E81AE28BAE4CBDDB3B35F187D26440752710@CHN-SV-EXMX02.mchp-main.com>
> Andrew,
>
> Admittedly, my knowledge of what the kernel is doing behind the
> scenes is limited.
Me too. Lets see if anybody can make sense of the information you
provided.
Thanks
Andrew
^ permalink raw reply
* [PATCH bpf-next v2] bpf: fix a compilation error when CONFIG_BPF_SYSCALL is not defined
From: Yonghong Song @ 2018-11-20 22:08 UTC (permalink / raw)
To: ast, daniel, netdev, kbuild-all; +Cc: kernel-team, Martin KaFai Lau
Kernel test robot (lkp@intel.com) reports a compilation error at
https://www.spinics.net/lists/netdev/msg534913.html
introduced by commit 838e96904ff3 ("bpf: Introduce bpf_func_info").
If CONFIG_BPF is defined and CONFIG_BPF_SYSCALL is not defined,
the following error will appear:
kernel/bpf/core.c:414: undefined reference to `btf_type_by_id'
kernel/bpf/core.c:415: undefined reference to `btf_name_by_offset'
When CONFIG_BPF_SYSCALL is not defined,
let us define stub inline functions for btf_type_by_id()
and btf_name_by_offset() in include/linux/btf.h.
This way, the compilation failure can be avoided.
Fixes: 838e96904ff3 ("bpf: Introduce bpf_func_info")
Reported-by: kbuild test robot <lkp@intel.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
---
include/linux/btf.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
Changelog:
v1 -> v2:
. Two functions should be static inline functions
if CONFIG_BPF_SYSCALL is not defined.
diff --git a/include/linux/btf.h b/include/linux/btf.h
index 7f2c0a4a45ea..8c2199b5d250 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -46,7 +46,21 @@ void btf_type_seq_show(const struct btf *btf, u32 type_id, void *obj,
struct seq_file *m);
int btf_get_fd_by_id(u32 id);
u32 btf_id(const struct btf *btf);
+
+#ifdef CONFIG_BPF_SYSCALL
const struct btf_type *btf_type_by_id(const struct btf *btf, u32 type_id);
const char *btf_name_by_offset(const struct btf *btf, u32 offset);
+#else
+static inline const struct btf_type *btf_type_by_id(const struct btf *btf,
+ u32 type_id)
+{
+ return NULL;
+}
+static inline const char *btf_name_by_offset(const struct btf *btf,
+ u32 offset)
+{
+ return NULL;
+}
+#endif
#endif
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v1 net] lan743x: fix return value for lan743x_tx_napi_poll
From: Florian Fainelli @ 2018-11-20 22:11 UTC (permalink / raw)
To: Bryan.Whitehead, andrew; +Cc: davem, netdev, UNGLinuxDriver
In-Reply-To: <90A7E81AE28BAE4CBDDB3B35F187D26440752710@CHN-SV-EXMX02.mchp-main.com>
On 11/20/18 1:39 PM, Bryan.Whitehead@microchip.com wrote:
>> -----Original Message-----
>> From: Andrew Lunn <andrew@lunn.ch>
>> Sent: Tuesday, November 20, 2018 2:31 PM
>> To: Bryan Whitehead - C21958 <Bryan.Whitehead@microchip.com>
>> Cc: davem@davemloft.net; netdev@vger.kernel.org; UNGLinuxDriver
>> <UNGLinuxDriver@microchip.com>
>> Subject: Re: [PATCH v1 net] lan743x: fix return value for
>> lan743x_tx_napi_poll
>>
>> On Tue, Nov 20, 2018 at 01:26:43PM -0500, Bryan Whitehead wrote:
>>> It has been noticed that under stress the lan743x driver will
>>> sometimes hang or cause a kernel panic. It has been noticed that
>>> returning '0' instead of 'weight' fixes this issue.
>>>
>>> fixes: rare kernel panic under heavy traffic load.
>>> Signed-off-by: Bryan Whitehead <Bryan.Whitehead@microchip.com>
>>
>> Hi Bryan
>>
>> This sounds like a band aid over something which is broken, not a real fix.
>>
>> Can you show us the stack trace from the panic?
>>
>> Andrew
>
> Andrew,
>
> Admittedly, my knowledge of what the kernel is doing behind the scenes is limited.
>
> But according to documentation found on
> https://wiki.linuxfoundation.org/networking/napi
>
> It states the following
> "The poll() function may also process TX completions, in which case if it processes
> the entire TX ring then it should count that work as the rest of the budget.
> Otherwise, TX completions are not counted."
>
> So based on that, the original driver was returning the full budget. But I was having
> Issues with it. And the above documentation seems to suggest that I could return 0
> As in "not counted" from above.
>
> I tried it, and my lock up issues disappeared.
>
> Regarding the kernel panic stack trace. So far its very hard to replicate that on the
> latest kernel. I've seen it more frequently when back porting to older kernels such
> as 4.14, and 4.9. This same fix caused those kernel panics to disappear.
> Are you interested in seeing a stack dump from older kernels?
>
> In the latest kernel the issue manifests as a kernel message which states
> "[ 945.021101] enp48s0: Budget exhausted after napi rescheduled"
>
> I'm not sure what that means. But it does not lock up immediately after seeing that
> Message. But it usually locks up with in a minute of seeing that message.
>
> And the sometimes I get the following warning
> [ 1240.425020] ------------[ cut here ]------------
> [ 1240.426014] NETDEV WATCHDOG: enp0s25 (e1000e): transmit queue 0 timed out
> [ 1240.430027] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x1ef/0x200
> [ 1240.430027] Modules linked in: lan743x
> [ 1240.430027] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G I 4.19.2 #1
> [ 1240.430027] Hardware name: Hewlett-Packard HP Compaq dc7900 Convertible Minitower/3032h, BIOS 786G1 v01.16 03/05/2009
> [ 1240.430027] RIP: 0010:dev_watchdog+0x1ef/0x200
> [ 1240.430027] Code: 00 48 63 4d e0 eb 93 4c 89 e7 c6 05 68 30 b3 00 01 e8 25 3d fd ff 89 d9 48 89 c2 4c 89 e6 48 c7 c7 98 92 48 ab e8 f1 28 87 ff <0f> 0b eb c0 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 48 c7 47 08 00
> [ 1240.430027] RSP: 0018:ffff98490be03e90 EFLAGS: 00010282
> [ 1240.430027] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> [ 1240.497168] RDX: 0000000000040400 RSI: 00000000000000f6 RDI: 0000000000000300
> [ 1240.497168] RBP: ffff984908574440 R08: 0000000000000000 R09: 00000000000003a4
> [ 1240.497168] R10: 0000000000000020 R11: ffffffffabc928ed R12: ffff984908574000
> [ 1240.497168] R13: 0000000000000000 R14: 0000000000000000 R15: ffff98490be195b0
> [ 1240.497168] FS: 0000000000000000(0000) GS:ffff98490be00000(0000) knlGS:0000000000000000
> [ 1240.497168] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1240.497168] CR2: 00007f31cd4c0000 CR3: 0000000109bca000 CR4: 00000000000406f0
> [ 1240.497168] Call Trace:
> [ 1240.497168] <IRQ>
> [ 1240.497168] ? qdisc_reset+0xe0/0xe0
> [ 1240.497168] call_timer_fn+0x26/0x130
> [ 1240.497168] run_timer_softirq+0x1cd/0x400
> [ 1240.497168] ? hpet_interrupt_handler+0x10/0x30
> [ 1240.497168] __do_softirq+0xed/0x2aa
> [ 1240.497168] irq_exit+0xb7/0xc0
> [ 1240.497168] do_IRQ+0x45/0xd0
> [ 1240.497168] common_interrupt+0xf/0xf
> [ 1240.497168] </IRQ>
> [ 1240.497168] RIP: 0010:cpuidle_enter_state+0xa6/0x330
> [ 1240.497168] Code: 65 8b 3d 1d b0 4d 55 e8 58 6a 95 ff 48 89 c3 66 66 66 66 90 31 ff e8 59 73 95 ff 80 7c 24 0b 00 0f 85 25 02 00 00 fb 4c 29 eb <48> ba cf f7 53 e3 a5 9b c4 20 48 89 d8 48 c1 fb 3f 48 f7 ea b8 ff
> [ 1240.497168] RSP: 0018:ffffffffab603e60 EFLAGS: 00000216 ORIG_RAX: ffffffffffffffde
> [ 1240.497168] RAX: ffff98490be20a80 RBX: 000000000081035c RCX: 00000120cf178c49
> [ 1240.497168] RDX: 00000120cf178ca0 RSI: 00000120cf178ca0 RDI: 0000000000000000
> [ 1240.497168] RBP: ffff984908fbd000 R08: fffffffb58ea5f9e R09: 000001208e0b48df
> [ 1240.497168] R10: 00000000000018c4 R11: 0000000000002468 R12: 0000000000000002
> [ 1240.497168] R13: 00000120ce968944 R14: ffffffffab6a68a0 R15: ffffffffab611740
> [ 1240.497168] do_idle+0x1da/0x230
> [ 1240.497168] cpu_startup_entry+0x6a/0x70
> [ 1240.497168] start_kernel+0x4a2/0x4c2
> [ 1240.497168] secondary_startup_64+0xa4/0xb0
> [ 1240.497168] ---[ end trace c6f3be34c214db4e ]---
>
> Notice the warning is referring to a different adapter. So I suspect that whatever happened it froze
> All network adapters.
>
> If you have suggestions let me know.
Did you look at the output of "perf top" or something along those lines
to figure out if your lan743x driver is indeed responsible for that by
not being scheduler friendly? What is likely happening is that you do
not reclaim "weight" packets and instead keep looping into NAPI context,
which prevents the system from making further progress.
Calling napi_complete_done() for the TX path is not necessary AFAICT,
what you really want to do is call napi_complete() and make sure you:
- reclaim/free as many TX buffers as possible, without looking at the
NAPI weight which becomes irrelevant
- if you have been able to reclaim enough descriptors, wake-up the
transmit queue
So ignoring the NAPI weight like you do is correct, but calling
napi_complete_done() with a 0 argument does not sound correct to me.
--
Florian
^ permalink raw reply
* Re: [PATCH bpf-next v2] libbpf: make sure bpf headers are c++ include-able
From: Y Song @ 2018-11-20 22:11 UTC (permalink / raw)
To: Stanislav Fomichev; +Cc: netdev, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <20181120213723.232615-1-sdf@google.com>
On Tue, Nov 20, 2018 at 1:37 PM Stanislav Fomichev <sdf@google.com> wrote:
>
> Wrap headers in extern "C", to turn off C++ mangling.
> This simplifies including libbpf in c++ and linking against it.
>
> v2 changes:
> * do the same for btf.h
>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Acked-by: Yonghong Song <yhs@fb.com>
> ---
> tools/lib/bpf/bpf.h | 9 +++++++++
> tools/lib/bpf/btf.h | 8 ++++++++
> tools/lib/bpf/libbpf.h | 9 +++++++++
> 3 files changed, 26 insertions(+)
^ permalink raw reply
* [PATCH mlx5-next 00/11] mlx5 core internal firmware events handling improvements
From: Saeed Mahameed @ 2018-11-20 22:12 UTC (permalink / raw)
To: Leon Romanovsky, saeedm; +Cc: netdev, linux-rdma, Jason Gunthorpe
Hi
This patchset is for mlx5-next shared branch, and will be applied there
once the review is done.
The main idea of this change is to define a flexible scalable and
simpler low level mlx5 core APIs to upper level components for better
features decoupling and maximum code locality and modularity.
Improve and simplify mlx5 core internal firmware and device async events
handling and subscription, currently all async firmware events are
handled in one place (switch case in eq.c) and every time we need to
update one of the mlx5_core handlers or add new events handling to the
system, the driver needs to be changed in many places in order to deliver
the new event to its consumer.
To improve this we will use atomic_notifier_chain to fire firmware events
at internal mlx5 core components such as eswitch/fpga/clock/FW tracer/etc..,
this is to avoid explicit calls from low level mlx5_core to upper components
and to simplify the mlx5_core API for future developments.
Provide register/unregister notifiers API and call the notifier chain on
firmware async events.
Example to subscribe to a FW event:
struct mlx5_nb port_event;
MLX5_NB_INIT(&port_event, port_event_handler, PORT_CHANGE);
mlx5_eq_notifier_register(mdev, &port_event);
Where:
- port_event_handler is the notifier block callback.
- PORT_EVENT is the suffix of MLX5_EVENT_TYPE_PORT_CHANGE (The event
type to subscribe to)
The above will guarantee that port_event_handler will receive all FW
events of the type MLX5_EVENT_TYPE_PORT_CHANGE.
To receive all FW/HW events one can subscribe to MLX5_EVENT_TYPE_NOTIFY_ANY.
There can be only 128 types of firmware events each has its own 64Byte
EQE (Event Queue Element) data, we will have one atomic_notifier_chain
per event type for maximum performance and verbosity.
Each handler is going to receive the event_type as unsigned long and
the event data as void pointer, exactly as defined in the notifier block
handlers prototype.
This API is implemented in the first patch of this series all following
patches are modifying the existing mlx5 components to use the new API to
subscribe to FW events.
Thanks,
Saeed.
---
Saeed Mahameed (11):
net/mlx5: EQ, Introduce atomic notifier chain subscription API
net/mlx5: FWTrace, Use async events chain
net/mlx5: FPGA, Use async events chain
net/mlx5: Clock, Use async events chain
net/mlx5: E-Switch, Use async events chain
net/mlx5: FWPage, Use async events chain
net/mlx5: CmdIF, Use async events chain
net/mlx5: Resource tables, Use async events chain
net/mlx5: CQ ERR, Use async events chain
net/mlx5: Device events, Use async events chain
net/mlx5: Improve core device events handling
.../net/ethernet/mellanox/mlx5/core/Makefile | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 48 ++-
.../mellanox/mlx5/core/diag/fw_tracer.c | 27 +-
.../mellanox/mlx5/core/diag/fw_tracer.h | 2 +-
.../ethernet/mellanox/mlx5/core/en_stats.c | 9 +-
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 322 +++++------------
.../net/ethernet/mellanox/mlx5/core/eswitch.c | 44 ++-
.../net/ethernet/mellanox/mlx5/core/eswitch.h | 3 +-
.../net/ethernet/mellanox/mlx5/core/events.c | 332 ++++++++++++++++++
.../ethernet/mellanox/mlx5/core/fpga/core.c | 38 +-
.../ethernet/mellanox/mlx5/core/fpga/core.h | 11 +-
.../net/ethernet/mellanox/mlx5/core/health.c | 25 +-
.../ethernet/mellanox/mlx5/core/lib/clock.c | 24 +-
.../ethernet/mellanox/mlx5/core/lib/clock.h | 3 -
.../net/ethernet/mellanox/mlx5/core/lib/eq.h | 5 +
.../ethernet/mellanox/mlx5/core/lib/mlx5.h | 34 ++
.../net/ethernet/mellanox/mlx5/core/main.c | 41 ++-
.../ethernet/mellanox/mlx5/core/mlx5_core.h | 13 +-
.../ethernet/mellanox/mlx5/core/pagealloc.c | 44 ++-
.../net/ethernet/mellanox/mlx5/core/port.c | 57 ---
drivers/net/ethernet/mellanox/mlx5/core/qp.c | 68 +++-
drivers/net/ethernet/mellanox/mlx5/core/srq.c | 55 ++-
include/linux/mlx5/device.h | 10 +-
include/linux/mlx5/driver.h | 46 +--
include/linux/mlx5/eq.h | 16 +-
include/linux/mlx5/port.h | 3 -
26 files changed, 811 insertions(+), 471 deletions(-)
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/events.c
--
2.19.1
^ permalink raw reply
* [PATCH mlx5-next 01/11] net/mlx5: EQ, Introduce atomic notifier chain subscription API
From: Saeed Mahameed @ 2018-11-20 22:12 UTC (permalink / raw)
To: Leon Romanovsky, saeedm; +Cc: netdev, linux-rdma, Jason Gunthorpe
In-Reply-To: <20181120221228.18365-1-saeedm@mellanox.com>
Use atomic_notifier_chain to fire firmware events at internal mlx5 core
components such as eswitch/fpga/clock/FW tracer/etc.., this is to
avoid explicit calls from low level mlx5_core to upper components and to
simplify the mlx5_core API for future developments.
Simply provide register/unregister notifiers API and call the notifier
chain on firmware async events.
Example: to subscribe to a FW event:
struct mlx5_nb port_event;
MLX5_NB_INIT(&port_event, port_event_handler, PORT_CHANGE);
mlx5_eq_notifier_register(mdev, &port_event);
where:
- port_event_handler is the notifier block callback.
- PORT_EVENT is the suffix of MLX5_EVENT_TYPE_PORT_CHANGE.
The above will guarantee that port_event_handler will receive all FW
events of the type MLX5_EVENT_TYPE_PORT_CHANGE.
To receive all FW/HW events one can subscribe to
MLX5_EVENT_TYPE_NOTIFY_ANY.
The next few patches will start moving all mlx5 core components to use
this new API and cleanup mlx5_eq_async_int misx handler from component
explicit calls and specific logic.
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 42 +++++++++++++++++--
.../net/ethernet/mellanox/mlx5/core/lib/eq.h | 5 +++
.../ethernet/mellanox/mlx5/core/mlx5_core.h | 5 +++
include/linux/mlx5/device.h | 10 ++++-
include/linux/mlx5/eq.h | 16 ++++++-
5 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eq.c b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
index 6ba8e401a0c7..34e4b2c246ff 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
@@ -31,6 +31,7 @@
*/
#include <linux/interrupt.h>
+#include <linux/notifier.h>
#include <linux/module.h>
#include <linux/mlx5/driver.h>
#include <linux/mlx5/eq.h>
@@ -68,8 +69,10 @@ struct mlx5_irq_info {
struct mlx5_eq_table {
struct list_head comp_eqs_list;
struct mlx5_eq pages_eq;
- struct mlx5_eq async_eq;
struct mlx5_eq cmd_eq;
+ struct mlx5_eq async_eq;
+
+ struct atomic_notifier_head nh[MLX5_EVENT_TYPE_MAX];
struct mutex lock; /* sync async eqs creations */
int num_comp_vectors;
@@ -316,13 +319,17 @@ u32 mlx5_eq_poll_irq_disabled(struct mlx5_eq_comp *eq)
static irqreturn_t mlx5_eq_async_int(int irq, void *eq_ptr)
{
struct mlx5_eq *eq = eq_ptr;
- struct mlx5_core_dev *dev = eq->dev;
+ struct mlx5_eq_table *eqt;
+ struct mlx5_core_dev *dev;
struct mlx5_eqe *eqe;
int set_ci = 0;
u32 cqn = -1;
u32 rsn;
u8 port;
+ dev = eq->dev;
+ eqt = dev->priv.eq_table;
+
while ((eqe = next_eqe_sw(eq))) {
/*
* Make sure we read EQ entry contents after we've
@@ -437,6 +444,13 @@ static irqreturn_t mlx5_eq_async_int(int irq, void *eq_ptr)
break;
}
+ if (likely(eqe->type < MLX5_EVENT_TYPE_MAX))
+ atomic_notifier_call_chain(&eqt->nh[eqe->type], eqe->type, eqe);
+ else
+ mlx5_core_warn_once(dev, "notifier_call_chain is not setup for eqe: %d\n", eqe->type);
+
+ atomic_notifier_call_chain(&eqt->nh[MLX5_EVENT_TYPE_NOTIFY_ANY], eqe->type, eqe);
+
++eq->cons_index;
++set_ci;
@@ -625,7 +639,7 @@ int mlx5_eq_del_cq(struct mlx5_eq *eq, struct mlx5_core_cq *cq)
int mlx5_eq_table_init(struct mlx5_core_dev *dev)
{
struct mlx5_eq_table *eq_table;
- int err;
+ int i, err;
eq_table = kvzalloc(sizeof(*eq_table), GFP_KERNEL);
if (!eq_table)
@@ -638,6 +652,8 @@ int mlx5_eq_table_init(struct mlx5_core_dev *dev)
goto kvfree_eq_table;
mutex_init(&eq_table->lock);
+ for (i = 0; i < MLX5_EVENT_TYPE_MAX; i++)
+ ATOMIC_INIT_NOTIFIER_HEAD(&eq_table->nh[i]);
return 0;
@@ -1202,3 +1218,23 @@ void mlx5_eq_table_destroy(struct mlx5_core_dev *dev)
destroy_async_eqs(dev);
free_irq_vectors(dev);
}
+
+int mlx5_eq_notifier_register(struct mlx5_core_dev *dev, struct mlx5_nb *nb)
+{
+ struct mlx5_eq_table *eqt = dev->priv.eq_table;
+
+ if (nb->event_type >= MLX5_EVENT_TYPE_MAX)
+ return -EINVAL;
+
+ return atomic_notifier_chain_register(&eqt->nh[nb->event_type], &nb->nb);
+}
+
+int mlx5_eq_notifier_unregister(struct mlx5_core_dev *dev, struct mlx5_nb *nb)
+{
+ struct mlx5_eq_table *eqt = dev->priv.eq_table;
+
+ if (nb->event_type >= MLX5_EVENT_TYPE_MAX)
+ return -EINVAL;
+
+ return atomic_notifier_chain_unregister(&eqt->nh[nb->event_type], &nb->nb);
+}
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/eq.h b/drivers/net/ethernet/mellanox/mlx5/core/lib/eq.h
index 6d8c8a57d52b..c0fb6d72b695 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lib/eq.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/eq.h
@@ -4,6 +4,8 @@
#ifndef __LIB_MLX5_EQ_H__
#define __LIB_MLX5_EQ_H__
#include <linux/mlx5/driver.h>
+#include <linux/mlx5/eq.h>
+#include <linux/mlx5/cq.h>
#define MLX5_MAX_IRQ_NAME (32)
#define MLX5_EQE_SIZE (sizeof(struct mlx5_eqe))
@@ -90,4 +92,7 @@ void mlx5_core_eq_free_irqs(struct mlx5_core_dev *dev);
struct cpu_rmap *mlx5_eq_table_get_rmap(struct mlx5_core_dev *dev);
#endif
+int mlx5_eq_notifier_register(struct mlx5_core_dev *dev, struct mlx5_nb *nb);
+int mlx5_eq_notifier_unregister(struct mlx5_core_dev *dev, struct mlx5_nb *nb);
+
#endif
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h b/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h
index 21727d9eeb84..e06c6e16ffc9 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h
@@ -78,6 +78,11 @@ do { \
__func__, __LINE__, current->pid, \
##__VA_ARGS__)
+#define mlx5_core_warn_once(__dev, format, ...) \
+ dev_warn_once(&(__dev)->pdev->dev, "%s:%d:(pid %d): " format, \
+ __func__, __LINE__, current->pid, \
+ ##__VA_ARGS__)
+
#define mlx5_core_info(__dev, format, ...) \
dev_info(&(__dev)->pdev->dev, format, ##__VA_ARGS__)
diff --git a/include/linux/mlx5/device.h b/include/linux/mlx5/device.h
index e326524bafcc..f7c8bebfe472 100644
--- a/include/linux/mlx5/device.h
+++ b/include/linux/mlx5/device.h
@@ -301,9 +301,15 @@ enum {
MLX5_EVENT_QUEUE_TYPE_DCT = 6,
};
+/* mlx5 components can subscribe to any one of these events via
+ * mlx5_eq_notifier_register API.
+ */
enum mlx5_event {
+ /* Special value to subscribe to any event */
+ MLX5_EVENT_TYPE_NOTIFY_ANY = 0x0,
+ /* HW events enum start: comp events are not subscribable */
MLX5_EVENT_TYPE_COMP = 0x0,
-
+ /* HW Async events enum start: subscribable events */
MLX5_EVENT_TYPE_PATH_MIG = 0x01,
MLX5_EVENT_TYPE_COMM_EST = 0x02,
MLX5_EVENT_TYPE_SQ_DRAINED = 0x03,
@@ -341,6 +347,8 @@ enum mlx5_event {
MLX5_EVENT_TYPE_FPGA_QP_ERROR = 0x21,
MLX5_EVENT_TYPE_DEVICE_TRACER = 0x26,
+
+ MLX5_EVENT_TYPE_MAX = MLX5_EVENT_TYPE_DEVICE_TRACER + 1,
};
enum {
diff --git a/include/linux/mlx5/eq.h b/include/linux/mlx5/eq.h
index 71d82c5a1a02..00045cc4ea11 100644
--- a/include/linux/mlx5/eq.h
+++ b/include/linux/mlx5/eq.h
@@ -4,8 +4,6 @@
#ifndef MLX5_CORE_EQ_H
#define MLX5_CORE_EQ_H
-#include <linux/mlx5/driver.h>
-
enum {
MLX5_EQ_PAGEREQ_IDX = 0,
MLX5_EQ_CMD_IDX = 1,
@@ -22,6 +20,7 @@ enum {
#define MLX5_NUM_SPARE_EQE (0x80)
struct mlx5_eq;
+struct mlx5_core_dev;
struct mlx5_eq_param {
u8 index;
@@ -57,4 +56,17 @@ static inline u32 mlx5_eq_update_cc(struct mlx5_eq *eq, u32 cc)
return cc;
}
+struct mlx5_nb {
+ struct notifier_block nb;
+ u8 event_type;
+};
+
+#define mlx5_nb_cof(ptr, type, member) \
+ (container_of(container_of(ptr, struct mlx5_nb, nb), type, member))
+
+#define MLX5_NB_INIT(name, handler, event) do { \
+ (name)->nb.notifier_call = handler; \
+ (name)->event_type = MLX5_EVENT_TYPE_##event; \
+} while (0)
+
#endif /* MLX5_CORE_EQ_H */
--
2.19.1
^ permalink raw reply related
* [PATCH mlx5-next 02/11] net/mlx5: FWTrace, Use async events chain
From: Saeed Mahameed @ 2018-11-20 22:12 UTC (permalink / raw)
To: Leon Romanovsky, saeedm; +Cc: netdev, linux-rdma, Jason Gunthorpe
In-Reply-To: <20181120221228.18365-1-saeedm@mellanox.com>
Remove the explicit call to mlx5_fw_tracer_event on
MLX5_EVENT_TYPE_DEVICE_TRACER and let fw tracer to register
its own handler when its ready.
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
.../mellanox/mlx5/core/diag/fw_tracer.c | 27 ++++++++++---------
.../mellanox/mlx5/core/diag/fw_tracer.h | 2 +-
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 4 ---
3 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c b/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c
index d4ec93bde4de..6999f4486e9e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c
@@ -30,6 +30,7 @@
* SOFTWARE.
*/
#define CREATE_TRACE_POINTS
+#include "lib/eq.h"
#include "fw_tracer.h"
#include "fw_tracer_tracepoint.h"
@@ -846,9 +847,9 @@ struct mlx5_fw_tracer *mlx5_fw_tracer_create(struct mlx5_core_dev *dev)
return ERR_PTR(err);
}
-/* Create HW resources + start tracer
- * must be called before Async EQ is created
- */
+static int fw_tracer_event(struct notifier_block *nb, unsigned long action, void *data);
+
+/* Create HW resources + start tracer */
int mlx5_fw_tracer_init(struct mlx5_fw_tracer *tracer)
{
struct mlx5_core_dev *dev;
@@ -874,6 +875,9 @@ int mlx5_fw_tracer_init(struct mlx5_fw_tracer *tracer)
goto err_dealloc_pd;
}
+ MLX5_NB_INIT(&tracer->nb, fw_tracer_event, DEVICE_TRACER);
+ mlx5_eq_notifier_register(dev, &tracer->nb);
+
mlx5_fw_tracer_start(tracer);
return 0;
@@ -883,9 +887,7 @@ int mlx5_fw_tracer_init(struct mlx5_fw_tracer *tracer)
return err;
}
-/* Stop tracer + Cleanup HW resources
- * must be called after Async EQ is destroyed
- */
+/* Stop tracer + Cleanup HW resources */
void mlx5_fw_tracer_cleanup(struct mlx5_fw_tracer *tracer)
{
if (IS_ERR_OR_NULL(tracer))
@@ -893,7 +895,7 @@ void mlx5_fw_tracer_cleanup(struct mlx5_fw_tracer *tracer)
mlx5_core_dbg(tracer->dev, "FWTracer: Cleanup, is owner ? (%d)\n",
tracer->owner);
-
+ mlx5_eq_notifier_unregister(tracer->dev, &tracer->nb);
cancel_work_sync(&tracer->ownership_change_work);
cancel_work_sync(&tracer->handle_traces_work);
@@ -922,12 +924,11 @@ void mlx5_fw_tracer_destroy(struct mlx5_fw_tracer *tracer)
kfree(tracer);
}
-void mlx5_fw_tracer_event(struct mlx5_core_dev *dev, struct mlx5_eqe *eqe)
+static int fw_tracer_event(struct notifier_block *nb, unsigned long action, void *data)
{
- struct mlx5_fw_tracer *tracer = dev->tracer;
-
- if (!tracer)
- return;
+ struct mlx5_fw_tracer *tracer = mlx5_nb_cof(nb, struct mlx5_fw_tracer, nb);
+ struct mlx5_core_dev *dev = tracer->dev;
+ struct mlx5_eqe *eqe = data;
switch (eqe->sub_type) {
case MLX5_TRACER_SUBTYPE_OWNERSHIP_CHANGE:
@@ -942,6 +943,8 @@ void mlx5_fw_tracer_event(struct mlx5_core_dev *dev, struct mlx5_eqe *eqe)
mlx5_core_dbg(dev, "FWTracer: Event with unrecognized subtype: sub_type %d\n",
eqe->sub_type);
}
+
+ return NOTIFY_OK;
}
EXPORT_TRACEPOINT_SYMBOL(mlx5_fw);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.h b/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.h
index 0347f2dd5cee..a8b8747f2b61 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.h
@@ -55,6 +55,7 @@
struct mlx5_fw_tracer {
struct mlx5_core_dev *dev;
+ struct mlx5_nb nb;
bool owner;
u8 trc_ver;
struct workqueue_struct *work_queue;
@@ -170,6 +171,5 @@ struct mlx5_fw_tracer *mlx5_fw_tracer_create(struct mlx5_core_dev *dev);
int mlx5_fw_tracer_init(struct mlx5_fw_tracer *tracer);
void mlx5_fw_tracer_cleanup(struct mlx5_fw_tracer *tracer);
void mlx5_fw_tracer_destroy(struct mlx5_fw_tracer *tracer);
-void mlx5_fw_tracer_event(struct mlx5_core_dev *dev, struct mlx5_eqe *eqe);
#endif
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eq.c b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
index 34e4b2c246ff..c7c436b0ed2e 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
@@ -434,10 +434,6 @@ static irqreturn_t mlx5_eq_async_int(int irq, void *eq_ptr)
general_event_handler(dev, eqe);
break;
- case MLX5_EVENT_TYPE_DEVICE_TRACER:
- mlx5_fw_tracer_event(dev, eqe);
- break;
-
default:
mlx5_core_warn(dev, "Unhandled event 0x%x on EQ 0x%x\n",
eqe->type, eq->eqn);
--
2.19.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