* Re: [PATCH net-next v2 0/4] bonding: performance and reliability
From: David Miller @ 2018-05-16 16:16 UTC (permalink / raw)
To: dbanerje; +Cc: netdev, j.vosburgh, vfalico, andy
In-Reply-To: <20180514184810.15506-1-dbanerje@akamai.com>
From: Debabrata Banerjee <dbanerje@akamai.com>
Date: Mon, 14 May 2018 14:48:06 -0400
> Series of fixes to how rlb updates are handled, code cleanup, allowing
> higher performance tx hashing in balance-alb mode, and reliability of
> link up/down monitoring.
>
> v2: refactor bond_is_nondyn_tlb with inline fn, update log comment to
> point out that multicast addresses will not get rlb updates.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] bonding: allow carrier and link status to determine link state
From: Jay Vosburgh @ 2018-05-16 16:11 UTC (permalink / raw)
To: Debabrata Banerjee
Cc: David S . Miller, netdev, Veaceslav Falico, Andy Gospodarek
In-Reply-To: <20180514184810.15506-5-dbanerje@akamai.com>
Debabrata Banerjee <dbanerje@akamai.com> wrote:
>In a mixed environment it may be difficult to tell if your hardware
>support carrier, if it does not it can always report true. With a new
>use_carrier option of 2, we can check both carrier and link status
>sequentially, instead of one or the other
Your reply in the prior discussion suggests to me that there is
a bug somewhere else (perhaps in bonding, perhaps in the network
driver), and this is just papering over it. As I said, I don't believe
that an additional hack to bonding is the appropriate way to resolve
this.
-J
>Signed-off-by: Debabrata Banerjee <dbanerje@akamai.com>
>---
> Documentation/networking/bonding.txt | 4 ++--
> drivers/net/bonding/bond_main.c | 12 ++++++++----
> drivers/net/bonding/bond_options.c | 7 ++++---
> 3 files changed, 14 insertions(+), 9 deletions(-)
>
>diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
>index 9ba04c0bab8d..f063730e7e73 100644
>--- a/Documentation/networking/bonding.txt
>+++ b/Documentation/networking/bonding.txt
>@@ -828,8 +828,8 @@ use_carrier
> MII / ETHTOOL ioctl method to determine the link state.
>
> A value of 1 enables the use of netif_carrier_ok(), a value of
>- 0 will use the deprecated MII / ETHTOOL ioctls. The default
>- value is 1.
>+ 0 will use the deprecated MII / ETHTOOL ioctls. A value of 2
>+ will check both. The default value is 1.
>
> xmit_hash_policy
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index f7f8a49cb32b..7e9652c4b35c 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -132,7 +132,7 @@ MODULE_PARM_DESC(downdelay, "Delay before considering link down, "
> "in milliseconds");
> module_param(use_carrier, int, 0);
> MODULE_PARM_DESC(use_carrier, "Use netif_carrier_ok (vs MII ioctls) in miimon; "
>- "0 for off, 1 for on (default)");
>+ "0 for off, 1 for on (default), 2 for carrier then legacy checks");
> module_param(mode, charp, 0);
> MODULE_PARM_DESC(mode, "Mode of operation; 0 for balance-rr, "
> "1 for active-backup, 2 for balance-xor, "
>@@ -434,12 +434,16 @@ static int bond_check_dev_link(struct bonding *bond,
> int (*ioctl)(struct net_device *, struct ifreq *, int);
> struct ifreq ifr;
> struct mii_ioctl_data *mii;
>+ bool carrier = true;
>
> if (!reporting && !netif_running(slave_dev))
> return 0;
>
> if (bond->params.use_carrier)
>- return netif_carrier_ok(slave_dev) ? BMSR_LSTATUS : 0;
>+ carrier = netif_carrier_ok(slave_dev) ? BMSR_LSTATUS : 0;
>+
>+ if (!carrier)
>+ return carrier;
>
> /* Try to get link status using Ethtool first. */
> if (slave_dev->ethtool_ops->get_link)
>@@ -4399,8 +4403,8 @@ static int bond_check_params(struct bond_params *params)
> downdelay = 0;
> }
>
>- if ((use_carrier != 0) && (use_carrier != 1)) {
>- pr_warn("Warning: use_carrier module parameter (%d), not of valid value (0/1), so it was set to 1\n",
>+ if (use_carrier < 0 || use_carrier > 2) {
>+ pr_warn("Warning: use_carrier module parameter (%d), not of valid value (0-2), so it was set to 1\n",
> use_carrier);
> use_carrier = 1;
> }
>diff --git a/drivers/net/bonding/bond_options.c b/drivers/net/bonding/bond_options.c
>index 8a945c9341d6..dba6cef05134 100644
>--- a/drivers/net/bonding/bond_options.c
>+++ b/drivers/net/bonding/bond_options.c
>@@ -164,9 +164,10 @@ static const struct bond_opt_value bond_primary_reselect_tbl[] = {
> };
>
> static const struct bond_opt_value bond_use_carrier_tbl[] = {
>- { "off", 0, 0},
>- { "on", 1, BOND_VALFLAG_DEFAULT},
>- { NULL, -1, 0}
>+ { "off", 0, 0},
>+ { "on", 1, BOND_VALFLAG_DEFAULT},
>+ { "both", 2, 0},
>+ { NULL, -1, 0}
> };
>
> static const struct bond_opt_value bond_all_slaves_active_tbl[] = {
>--
>2.17.0
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* [PATCH v3 iproute2-next 3/3] rdma: update man pages
From: Steve Wise @ 2018-05-15 20:41 UTC (permalink / raw)
To: dsahern, leon; +Cc: stephen, netdev, linux-rdma
In-Reply-To: <cover.1526483157.git.swise@opengridcomputing.com>
Update the man pages for the resource attributes as well
as the driver-specific attributes.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
---
man/man8/rdma-resource.8 | 29 ++++++++++++++++++++++++++---
man/man8/rdma.8 | 2 +-
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/man/man8/rdma-resource.8 b/man/man8/rdma-resource.8
index ff5d25d..40b073d 100644
--- a/man/man8/rdma-resource.8
+++ b/man/man8/rdma-resource.8
@@ -7,13 +7,16 @@ rdma-resource \- rdma resource configuration
.in +8
.ti -8
.B rdma
-.RI "[ " OPTIONS " ]"
-.B resource
-.RI " { " COMMAND " | "
+.RI "[ " OPTIONS " ] " RESOURCE " { " COMMAND " | "
.BR help " }"
.sp
.ti -8
+.IR RESOURCE " := { "
+.BR cm_id " | " cq " | " mr " | " pd " | " qp " }"
+.sp
+
+.ti -8
.IR OPTIONS " := { "
\fB\-j\fR[\fIson\fR] |
\fB\-d\fR[\fIetails\fR] }
@@ -70,11 +73,31 @@ rdma res show qp link mlx5_4/- -d
Detailed view.
.RE
.PP
+rdma res show qp link mlx5_4/- -dd
+.RS 4
+Detailed view including driver-specific details.
+.RE
+.PP
rdma res show qp link mlx5_4/1 lqpn 0-6
.RS 4
Limit to specific Local QPNs.
.RE
.PP
+rdma resource show cm_id dst-port 7174
+.RS 4
+Show CM_IDs with destination ip port of 7174.
+.RE
+.PP
+rdma resource show cm_id src-addr 172.16.0.100
+.RS 4
+Show CM_IDs bound to local ip address 172.16.0.100
+.RE
+.PP
+rdma resource show cq pid 30489
+.RS 4
+Show CQs belonging to pid 30489
+.RE
+.PP
.SH SEE ALSO
.BR rdma (8),
diff --git a/man/man8/rdma.8 b/man/man8/rdma.8
index 6f88f37..12aa149 100644
--- a/man/man8/rdma.8
+++ b/man/man8/rdma.8
@@ -49,7 +49,7 @@ If there were any errors during execution of the commands, the application retur
.TP
.BR "\-d" , " --details"
-Output detailed information.
+Output detailed information. Adding a second \-d includes driver-specific details.
.TP
.BR "\-p" , " --pretty"
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 iproute2-next 2/3] rdma: print driver resource attributes
From: Steve Wise @ 2018-05-15 20:41 UTC (permalink / raw)
To: dsahern, leon; +Cc: stephen, netdev, linux-rdma
In-Reply-To: <cover.1526483157.git.swise@opengridcomputing.com>
This enhancement allows printing rdma device-specific state, if provided
by the kernel. This is done in a generic manner, so rdma tool doesn't
need to know about the details of every type of rdma device.
Driver attributes for a rdma resource are in the form of <key,
[print_type], value> tuples, where the key is a string and the value can
be any supported driver attribute. The print_type attribute, if present,
provides a print format to use vs the standard print format for the type.
For example, the default print type for a PROVIDER_S32 value is "%d ",
but "0x%x " if the print_type of PRINT_TYPE_HEX is included inthe tuple.
Driver resources are only printed when the -dd flag is present.
If -p is present, then the output is formatted to not exceed 80 columns,
otherwise it is printed as a single row to be grep/awk friendly.
Example output:
# rdma resource show qp lqpn 1028 -dd -p
link cxgb4_0/- lqpn 1028 rqpn 0 type RC state RTS rq-psn 0 sq-psn 0 path-mig-state MIGRATED pid 0 comm [nvme_rdma]
sqid 1028 flushed 0 memsize 123968 cidx 85 pidx 85 wq_pidx 106 flush_cidx 85 in_use 0
size 386 flags 0x0 rqid 1029 memsize 16768 cidx 43 pidx 41 wq_pidx 171 msn 44 rqt_hwaddr 0x2a8a5d00
rqt_size 256 in_use 128 size 130
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
---
rdma/rdma.c | 9 ++-
rdma/rdma.h | 11 ++++
rdma/res.c | 30 +++------
rdma/utils.c | 196 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 224 insertions(+), 22 deletions(-)
diff --git a/rdma/rdma.c b/rdma/rdma.c
index b43e538..010e983 100644
--- a/rdma/rdma.c
+++ b/rdma/rdma.c
@@ -129,13 +129,14 @@ int main(int argc, char **argv)
{ "batch", required_argument, NULL, 'b' },
{ NULL, 0, NULL, 0 }
};
+ bool show_driver_details = false;
const char *batch_file = NULL;
bool pretty_output = false;
bool show_details = false;
bool json_output = false;
bool force = false;
- char *filename;
struct rd rd = {};
+ char *filename;
int opt;
int err;
@@ -152,7 +153,10 @@ int main(int argc, char **argv)
pretty_output = true;
break;
case 'd':
- show_details = true;
+ if (show_details)
+ show_driver_details = true;
+ else
+ show_details = true;
break;
case 'j':
json_output = true;
@@ -180,6 +184,7 @@ int main(int argc, char **argv)
argv += optind;
rd.show_details = show_details;
+ rd.show_driver_details = show_driver_details;
rd.json_output = json_output;
rd.pretty_output = pretty_output;
diff --git a/rdma/rdma.h b/rdma/rdma.h
index 1908fc4..fcaf9e6 100644
--- a/rdma/rdma.h
+++ b/rdma/rdma.h
@@ -55,6 +55,7 @@ struct rd {
char **argv;
char *filename;
bool show_details;
+ bool show_driver_details;
struct list_head dev_map_list;
uint32_t dev_idx;
uint32_t port_idx;
@@ -115,4 +116,14 @@ int rd_recv_msg(struct rd *rd, mnl_cb_t callback, void *data, uint32_t seq);
void rd_prepare_msg(struct rd *rd, uint32_t cmd, uint32_t *seq, uint16_t flags);
int rd_dev_init_cb(const struct nlmsghdr *nlh, void *data);
int rd_attr_cb(const struct nlattr *attr, void *data);
+int rd_attr_check(const struct nlattr *attr, int *typep);
+
+/*
+ * Print helpers
+ */
+void print_driver_table(struct rd *rd, struct nlattr *tb);
+void newline(struct rd *rd);
+void newline_indent(struct rd *rd);
+#define MAX_LINE_LENGTH 80
+
#endif /* _RDMA_TOOL_H_ */
diff --git a/rdma/res.c b/rdma/res.c
index 1a0aab6..074b992 100644
--- a/rdma/res.c
+++ b/rdma/res.c
@@ -439,10 +439,8 @@ static int res_qp_parse_cb(const struct nlmsghdr *nlh, void *data)
if (nla_line[RDMA_NLDEV_ATTR_RES_PID])
free(comm);
- if (rd->json_output)
- jsonw_end_array(rd->jw);
- else
- pr_out("\n");
+ print_driver_table(rd, nla_line[RDMA_NLDEV_ATTR_DRIVER]);
+ newline(rd);
}
return MNL_CB_OK;
}
@@ -678,10 +676,8 @@ static int res_cm_id_parse_cb(const struct nlmsghdr *nlh, void *data)
if (nla_line[RDMA_NLDEV_ATTR_RES_PID])
free(comm);
- if (rd->json_output)
- jsonw_end_array(rd->jw);
- else
- pr_out("\n");
+ print_driver_table(rd, nla_line[RDMA_NLDEV_ATTR_DRIVER]);
+ newline(rd);
}
return MNL_CB_OK;
}
@@ -804,10 +800,8 @@ static int res_cq_parse_cb(const struct nlmsghdr *nlh, void *data)
if (nla_line[RDMA_NLDEV_ATTR_RES_PID])
free(comm);
- if (rd->json_output)
- jsonw_end_array(rd->jw);
- else
- pr_out("\n");
+ print_driver_table(rd, nla_line[RDMA_NLDEV_ATTR_DRIVER]);
+ newline(rd);
}
return MNL_CB_OK;
}
@@ -919,10 +913,8 @@ static int res_mr_parse_cb(const struct nlmsghdr *nlh, void *data)
if (nla_line[RDMA_NLDEV_ATTR_RES_PID])
free(comm);
- if (rd->json_output)
- jsonw_end_array(rd->jw);
- else
- pr_out("\n");
+ print_driver_table(rd, nla_line[RDMA_NLDEV_ATTR_DRIVER]);
+ newline(rd);
}
return MNL_CB_OK;
}
@@ -1004,10 +996,8 @@ static int res_pd_parse_cb(const struct nlmsghdr *nlh, void *data)
if (nla_line[RDMA_NLDEV_ATTR_RES_PID])
free(comm);
- if (rd->json_output)
- jsonw_end_array(rd->jw);
- else
- pr_out("\n");
+ print_driver_table(rd, nla_line[RDMA_NLDEV_ATTR_DRIVER]);
+ newline(rd);
}
return MNL_CB_OK;
}
diff --git a/rdma/utils.c b/rdma/utils.c
index 49c967f..79c3d9f 100644
--- a/rdma/utils.c
+++ b/rdma/utils.c
@@ -11,6 +11,7 @@
#include "rdma.h"
#include <ctype.h>
+#include <inttypes.h>
int rd_argc(struct rd *rd)
{
@@ -393,8 +394,32 @@ static const enum mnl_attr_data_type nldev_policy[RDMA_NLDEV_ATTR_MAX] = {
[RDMA_NLDEV_ATTR_RES_MRLEN] = MNL_TYPE_U64,
[RDMA_NLDEV_ATTR_NDEV_INDEX] = MNL_TYPE_U32,
[RDMA_NLDEV_ATTR_NDEV_NAME] = MNL_TYPE_NUL_STRING,
+ [RDMA_NLDEV_ATTR_DRIVER] = MNL_TYPE_NESTED,
+ [RDMA_NLDEV_ATTR_DRIVER_ENTRY] = MNL_TYPE_NESTED,
+ [RDMA_NLDEV_ATTR_DRIVER_STRING] = MNL_TYPE_NUL_STRING,
+ [RDMA_NLDEV_ATTR_DRIVER_PRINT_TYPE] = MNL_TYPE_U8,
+ [RDMA_NLDEV_ATTR_DRIVER_S32] = MNL_TYPE_U32,
+ [RDMA_NLDEV_ATTR_DRIVER_U32] = MNL_TYPE_U32,
+ [RDMA_NLDEV_ATTR_DRIVER_S64] = MNL_TYPE_U64,
+ [RDMA_NLDEV_ATTR_DRIVER_U64] = MNL_TYPE_U64,
};
+int rd_attr_check(const struct nlattr *attr, int *typep)
+{
+ int type;
+
+ if (mnl_attr_type_valid(attr, RDMA_NLDEV_ATTR_MAX) < 0)
+ return MNL_CB_ERROR;
+
+ type = mnl_attr_get_type(attr);
+
+ if (mnl_attr_validate(attr, nldev_policy[type]) < 0)
+ return MNL_CB_ERROR;
+
+ *typep = nldev_policy[type];
+ return MNL_CB_OK;
+}
+
int rd_attr_cb(const struct nlattr *attr, void *data)
{
const struct nlattr **tb = data;
@@ -660,3 +685,174 @@ struct dev_map *dev_map_lookup(struct rd *rd, bool allow_port_index)
free(dev_name);
return dev_map;
}
+
+#define nla_type(attr) ((attr)->nla_type & NLA_TYPE_MASK)
+
+void newline(struct rd *rd)
+{
+ if (rd->json_output)
+ jsonw_end_array(rd->jw);
+ else
+ pr_out("\n");
+}
+
+void newline_indent(struct rd *rd)
+{
+ newline(rd);
+ if (!rd->json_output)
+ pr_out(" ");
+}
+
+static int print_driver_string(struct rd *rd, const char *key_str,
+ const char *val_str)
+{
+ if (rd->json_output) {
+ jsonw_string_field(rd->jw, key_str, val_str);
+ return 0;
+ } else {
+ return pr_out("%s %s ", key_str, val_str);
+ }
+}
+
+static int print_driver_s32(struct rd *rd, const char *key_str, int32_t val,
+ enum rdma_nldev_print_type print_type)
+{
+ if (rd->json_output) {
+ jsonw_int_field(rd->jw, key_str, val);
+ return 0;
+ }
+ switch (print_type) {
+ case RDMA_NLDEV_PRINT_TYPE_UNSPEC:
+ return pr_out("%s %d ", key_str, val);
+ case RDMA_NLDEV_PRINT_TYPE_HEX:
+ return pr_out("%s 0x%x ", key_str, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int print_driver_u32(struct rd *rd, const char *key_str, uint32_t val,
+ enum rdma_nldev_print_type print_type)
+{
+ if (rd->json_output) {
+ jsonw_int_field(rd->jw, key_str, val);
+ return 0;
+ }
+ switch (print_type) {
+ case RDMA_NLDEV_PRINT_TYPE_UNSPEC:
+ return pr_out("%s %u ", key_str, val);
+ case RDMA_NLDEV_PRINT_TYPE_HEX:
+ return pr_out("%s 0x%x ", key_str, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int print_driver_s64(struct rd *rd, const char *key_str, int64_t val,
+ enum rdma_nldev_print_type print_type)
+{
+ if (rd->json_output) {
+ jsonw_int_field(rd->jw, key_str, val);
+ return 0;
+ }
+ switch (print_type) {
+ case RDMA_NLDEV_PRINT_TYPE_UNSPEC:
+ return pr_out("%s %" PRId64 " ", key_str, val);
+ case RDMA_NLDEV_PRINT_TYPE_HEX:
+ return pr_out("%s 0x%" PRIx64 " ", key_str, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int print_driver_u64(struct rd *rd, const char *key_str, uint64_t val,
+ enum rdma_nldev_print_type print_type)
+{
+ if (rd->json_output) {
+ jsonw_int_field(rd->jw, key_str, val);
+ return 0;
+ }
+ switch (print_type) {
+ case RDMA_NLDEV_PRINT_TYPE_UNSPEC:
+ return pr_out("%s %" PRIu64 " ", key_str, val);
+ case RDMA_NLDEV_PRINT_TYPE_HEX:
+ return pr_out("%s 0x%" PRIx64 " ", key_str, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int print_driver_entry(struct rd *rd, struct nlattr *key_attr,
+ struct nlattr *val_attr,
+ enum rdma_nldev_print_type print_type)
+{
+ const char *key_str = mnl_attr_get_str(key_attr);
+ int attr_type = nla_type(val_attr);
+
+ switch (attr_type) {
+ case RDMA_NLDEV_ATTR_DRIVER_STRING:
+ return print_driver_string(rd, key_str,
+ mnl_attr_get_str(val_attr));
+ case RDMA_NLDEV_ATTR_DRIVER_S32:
+ return print_driver_s32(rd, key_str,
+ mnl_attr_get_u32(val_attr), print_type);
+ case RDMA_NLDEV_ATTR_DRIVER_U32:
+ return print_driver_u32(rd, key_str,
+ mnl_attr_get_u32(val_attr), print_type);
+ case RDMA_NLDEV_ATTR_DRIVER_S64:
+ return print_driver_s64(rd, key_str,
+ mnl_attr_get_u64(val_attr), print_type);
+ case RDMA_NLDEV_ATTR_DRIVER_U64:
+ return print_driver_u64(rd, key_str,
+ mnl_attr_get_u64(val_attr), print_type);
+ }
+ return -EINVAL;
+}
+
+void print_driver_table(struct rd *rd, struct nlattr *tb)
+{
+ int print_type = RDMA_NLDEV_PRINT_TYPE_UNSPEC;
+ struct nlattr *tb_entry, *key = NULL, *val;
+ int type, cc = 0;
+ int ret;
+
+ if (!rd->show_driver_details || !tb)
+ return;
+
+ if (rd->pretty_output)
+ newline_indent(rd);
+
+ /*
+ * Driver attrs are tuples of {key, [print-type], value}.
+ * The key must be a string. If print-type is present, it
+ * defines an alternate printf format type vs the native format
+ * for the attribute. And the value can be any available
+ * driver type.
+ */
+ mnl_attr_for_each_nested(tb_entry, tb) {
+
+ if (cc > MAX_LINE_LENGTH) {
+ if (rd->pretty_output)
+ newline_indent(rd);
+ cc = 0;
+ }
+ if (rd_attr_check(tb_entry, &type) != MNL_CB_OK)
+ return;
+ if (!key) {
+ if (type != MNL_TYPE_NUL_STRING)
+ return;
+ key = tb_entry;
+ } else if (type == MNL_TYPE_U8) {
+ print_type = mnl_attr_get_u8(tb_entry);
+ } else {
+ val = tb_entry;
+ ret = print_driver_entry(rd, key, val, print_type);
+ if (ret < 0)
+ return;
+ cc += ret;
+ print_type = RDMA_NLDEV_PRINT_TYPE_UNSPEC;
+ key = NULL;
+ }
+ }
+ return;
+}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 iproute2-next 1/3] rdma: update rdma_netlink.h to get new driver attributes
From: Steve Wise @ 2018-05-15 20:41 UTC (permalink / raw)
To: dsahern, leon; +Cc: stephen, netdev, linux-rdma
In-Reply-To: <cover.1526483157.git.swise@opengridcomputing.com>
Pull in the rdma_netlink.h changes from kernel
commits:
25a0ad85156a ("RDMA/nldev: Add explicit pad attribute")
da5c85078215 ("RDMA/nldev: add driver-specific resource tracking)"
0d52d803767e ("RDMA/uapi: Fix uapi breakage")
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
---
rdma/include/uapi/rdma/rdma_netlink.h | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/rdma/include/uapi/rdma/rdma_netlink.h b/rdma/include/uapi/rdma/rdma_netlink.h
index 60416ed..6513fb8 100644
--- a/rdma/include/uapi/rdma/rdma_netlink.h
+++ b/rdma/include/uapi/rdma/rdma_netlink.h
@@ -249,10 +249,22 @@ enum rdma_nldev_command {
RDMA_NLDEV_NUM_OPS
};
+enum {
+ RDMA_NLDEV_ATTR_ENTRY_STRLEN = 16,
+};
+
+enum rdma_nldev_print_type {
+ RDMA_NLDEV_PRINT_TYPE_UNSPEC,
+ RDMA_NLDEV_PRINT_TYPE_HEX,
+};
+
enum rdma_nldev_attr {
/* don't change the order or add anything between, this is ABI! */
RDMA_NLDEV_ATTR_UNSPEC,
+ /* Pad attribute for 64b alignment */
+ RDMA_NLDEV_ATTR_PAD = RDMA_NLDEV_ATTR_UNSPEC,
+
/* Identifier for ib_device */
RDMA_NLDEV_ATTR_DEV_INDEX, /* u32 */
@@ -387,7 +399,6 @@ enum rdma_nldev_attr {
RDMA_NLDEV_ATTR_RES_PD_ENTRY, /* nested table */
RDMA_NLDEV_ATTR_RES_LOCAL_DMA_LKEY, /* u32 */
RDMA_NLDEV_ATTR_RES_UNSAFE_GLOBAL_RKEY, /* u32 */
-
/*
* Provides logical name and index of netdevice which is
* connected to physical port. This information is relevant
@@ -400,7 +411,24 @@ enum rdma_nldev_attr {
*/
RDMA_NLDEV_ATTR_NDEV_INDEX, /* u32 */
RDMA_NLDEV_ATTR_NDEV_NAME, /* string */
+ /*
+ * driver-specific attributes.
+ */
+ RDMA_NLDEV_ATTR_DRIVER, /* nested table */
+ RDMA_NLDEV_ATTR_DRIVER_ENTRY, /* nested table */
+ RDMA_NLDEV_ATTR_DRIVER_STRING, /* string */
+ /*
+ * u8 values from enum rdma_nldev_print_type
+ */
+ RDMA_NLDEV_ATTR_DRIVER_PRINT_TYPE, /* u8 */
+ RDMA_NLDEV_ATTR_DRIVER_S32, /* s32 */
+ RDMA_NLDEV_ATTR_DRIVER_U32, /* u32 */
+ RDMA_NLDEV_ATTR_DRIVER_S64, /* s64 */
+ RDMA_NLDEV_ATTR_DRIVER_U64, /* u64 */
+ /*
+ * Always the end
+ */
RDMA_NLDEV_ATTR_MAX
};
#endif /* _RDMA_NETLINK_H */
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 iproute2-next 0/3] RDMA tool driver-specific resource tracking
From: Steve Wise @ 2018-05-16 15:05 UTC (permalink / raw)
To: dsahern, leon; +Cc: stephen, netdev, linux-rdma
This series enhances the iproute2 rdma tool to include displaying
driver-specific resource attributes. It is the user-space part of the
kernel driver resource tracking series that has been accepted for merging
into linux-4.18 [1]
If there are no additional review comments, it can now be merged, I think.
Changes since v2:
- resync rdma_netlink.h to fix uapi break
Changes since v1:
- commit log editorial fixes
- cite kernel commits that updated rdma_netlink.h in the
iproute2 commit syncing this header
- reorder stack definitions ala "reverse christmas tree"
- correctly handle unknown driver attributes when printing
Changes since v0/rfc:
- changed "provider" to "driver" based on kernel side changes
- updated man pages
- removed "RFC" tag
Thanks,
Steve.
[1] https://www.spinics.net/lists/linux-rdma/msg64199.html
Steve Wise (3):
rdma: update rdma_netlink.h to get new driver attributes
rdma: print driver resource attributes
rdma: update man pages
man/man8/rdma-resource.8 | 29 ++++-
man/man8/rdma.8 | 2 +-
rdma/include/uapi/rdma/rdma_netlink.h | 30 +++++-
rdma/rdma.c | 9 +-
rdma/rdma.h | 11 ++
rdma/res.c | 30 ++----
rdma/utils.c | 196 ++++++++++++++++++++++++++++++++++
7 files changed, 280 insertions(+), 27 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH v3] ipvlan: call netdevice notifier when master mac address changed
From: David Miller @ 2018-05-16 16:00 UTC (permalink / raw)
To: liuqifa
Cc: dsahern, maheshb, weiyongjun1, maowenan, dingtianhong, netdev,
linux-kernel
In-Reply-To: <20180514113809.10196-1-liuqifa@huawei.com>
From: <liuqifa@huawei.com>
Date: Mon, 14 May 2018 19:38:09 +0800
> From: Keefe Liu <liuqifa@huawei.com>
>
> When master device's mac has been changed, the commit
> 32c10bbfe914 ("ipvlan: always use the current L2 addr of the
> master") makes the IPVlan devices's mac changed also, but it
> doesn't do related works such as flush the IPVlan devices's
> arp table.
>
> Signed-off-by: Keefe Liu <liuqifa@huawei.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [GIT PULL 00/11] perf/core improvements and fixes
From: Ingo Molnar @ 2018-05-16 15:58 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Clark Williams, linux-kernel, linux-perf-users, Adrian Hunter,
Agustin Vega-Frias, Alexander Shishkin, Andi Kleen,
Andy Lutomirski, Daniel Borkmann, Dave Hansen, David Ahern,
Ganapatrao Kulkarni, H . Peter Anvin, Jin Yao, Jiri Olsa,
Joerg Roedel, Kan Liang, Masami Hiramatsu, Namhyung Kim, netdev,
Peter
In-Reply-To: <20180516144908.22212-1-acme@kernel.org>
* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Hi Ingo,
>
> Please consider pulling, more to come as I go thru Adrian's x86
> PTI series and the C++ support improvements to 'perf probe', from
> Holger,
>
> Best Regards,
>
> - Arnaldo
>
> Test results at the end of this message, as usual.
>
> The following changes since commit 291c161f6c65530092903fbea58eb07a62b220ba:
>
> Merge remote-tracking branch 'tip/perf/urgent' into perf/core (2018-05-15 10:30:17 -0300)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-4.18-20180516
>
> for you to fetch changes up to 7a36a287de9fbb1ba906e70573d3f2315f7fd609:
>
> perf bpf: Fix NULL return handling in bpf__prepare_load() (2018-05-16 10:01:55 -0300)
>
> ----------------------------------------------------------------
> perf/core improvements and fixes:
>
> - Add '-e intel_pt//u' test to the 'parse-events' 'perf test' entry,
> to help avoiding regressions in the events parser such as one
> that caused a revert in v4.17-rc (Arnaldo Carvalho de Melo)
>
> - Fix NULL return handling in bpf__prepare_load() (YueHaibing)
>
> - Warn about 'perf buildid-cache --purge-all' failures (Ravi Bangoria)
>
> - Add infrastructure to help in writing eBPF C programs to be used
> with '-e name.c' type events in tools such as 'record' and 'trace',
> with headers for common constructs and an examples directory that
> will get populated as we add more such helpers and the 'perf bpf'
> branch that Jiri Olsa has been working on (Arnaldo Carvalho de Melo)
>
> - Handle uncore event aliases in small groups properly (Kan Liang)
>
> - Use the "_stest" symbol to identify the kernel map when loading kcore (Adrian Hunter)
>
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> ----------------------------------------------------------------
> Adrian Hunter (1):
> perf tools: Use the "_stest" symbol to identify the kernel map when loading kcore
>
> Arnaldo Carvalho de Melo (7):
> perf tests parse-events: Add intel_pt parse test
> perf llvm-utils: Add bpf include path to clang command line
> perf bpf: Add 'examples' directories
> perf bpf: Add bpf.h to be used in eBPF proggies
> perf bpf: Add kprobe example to catch 5s naps
> perf bpf: Add license(NAME) helper
> perf bpf: Add probe() helper to reduce kprobes boilerplate
>
> Kan Liang (1):
> perf parse-events: Handle uncore event aliases in small groups properly
>
> Ravi Bangoria (1):
> perf buildid-cache: Warn --purge-all failures
>
> YueHaibing (1):
> perf bpf: Fix NULL return handling in bpf__prepare_load()
>
> tools/perf/Makefile.config | 14 ++++
> tools/perf/Makefile.perf | 8 +++
> tools/perf/builtin-buildid-cache.c | 8 ++-
> tools/perf/examples/bpf/5sec.c | 49 ++++++++++++++
> tools/perf/examples/bpf/empty.c | 3 +
> tools/perf/include/bpf/bpf.h | 13 ++++
> tools/perf/tests/parse-events.c | 13 ++++
> tools/perf/util/Build | 2 +
> tools/perf/util/bpf-loader.c | 6 +-
> tools/perf/util/evsel.h | 1 +
> tools/perf/util/llvm-utils.c | 19 ++++--
> tools/perf/util/parse-events.c | 130 ++++++++++++++++++++++++++++++++++++-
> tools/perf/util/parse-events.h | 7 +-
> tools/perf/util/parse-events.y | 8 +--
> tools/perf/util/symbol.c | 16 ++---
> 15 files changed, 270 insertions(+), 27 deletions(-)
> create mode 100644 tools/perf/examples/bpf/5sec.c
> create mode 100644 tools/perf/examples/bpf/empty.c
> create mode 100644 tools/perf/include/bpf/bpf.h
Pulled, thanks a lot Arnaldo!
Ingo
^ permalink raw reply
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Vlad Buslov @ 2018-05-16 15:53 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Roman Mashak, Linux Kernel Network Developers, David Miller,
Cong Wang, Jiri Pirko, pablo, kadlec, fw, ast, Daniel Borkmann,
Eric Dumazet, kliteyn
In-Reply-To: <0426e39c-e9fd-50b1-3611-a804a965df50@mojatatu.com>
On Wed 16 May 2018 at 15:02, Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 16/05/18 10:38 AM, Roman Mashak wrote:
>
>>>>
>>>> You may actually have broken something with your patches in this case.
>>>
>>> Results is for net-next without my patches.
>>
>> Do you have skbmod compiled in kernel or as a module?
>>
>
> Also - suggestion is to use latest iproute2 which interprets
> extended error information (instead of the classical
> "We have an error talking to the kernel").
>
> cheers,
> jamal
I have very recent iproute2 installed. Last commit date is May 9th.
^ permalink raw reply
* Re: [PATCH net-next 00/10] net/smc: enhancements 2018/05/15
From: David Miller @ 2018-05-16 15:51 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <20180515150503.47265-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Tue, 15 May 2018 17:04:53 +0200
> here are smc patches for net-next. The first one is a fix for net-next
> commit 01d2f7e2cdd3 "net/smc: sockopts TCP_NODELAY and TCP_CORK".
> Patch 7 improves Connection Layer Control error handling, patch 10
> improves abnormal termination of link groups. The remaining patches
> from Karsten improve Link Layer Control code.
Series applied, thank you.
^ permalink raw reply
* Re: [RFC PATCH bpf-next 12/12] i40e: implement Tx zero-copy
From: Magnus Karlsson @ 2018-05-16 15:38 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Björn Töpel, Karlsson, Magnus, Alexander Duyck,
Alexander Duyck, John Fastabend, Alexei Starovoitov,
Willem de Bruijn, Daniel Borkmann, Michael S. Tsirkin,
Network Development, michael.lundkvist, Brandeburg, Jesse,
Singhai, Anjali, Zhang, Qi Z, intel-wired-lan
In-Reply-To: <CAJ8uoz39PnGmQ63VWezG1EBEM+ODrWSjZqKNGeO5oexvGs3pXA@mail.gmail.com>
On Wed, May 16, 2018 at 4:38 PM, Magnus Karlsson
<magnus.karlsson@gmail.com> wrote:
> On Wed, May 16, 2018 at 4:28 PM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
>> On Tue, 15 May 2018 21:06:15 +0200
>> Björn Töpel <bjorn.topel@gmail.com> wrote:
>>
>>> From: Magnus Karlsson <magnus.karlsson@intel.com>
>>>
>>> Here, the zero-copy ndo is implemented. As a shortcut, the existing
>>> XDP Tx rings are used for zero-copy. This means that and XDP program
>>> cannot redirect to an AF_XDP enabled XDP Tx ring.
>>
>> I've changed i40e1 to only have one queue via:
>> $ ethtool -L i40e1 combined 1
>>
>> And then, I'm sending on queue 1, which is/should not be avail... and then crash/BUG:
>>
>> $ sudo taskset -c 2 ./xdpsock --tx --interface=i40e1 --queue=1
>>
>> [ 3799.936877] Number of in use tx queues changed invalidating tc mappings. Priority traffic
>> classification disabled!
>> [ 3799.972970] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
>> [ 3799.980790] PGD 80000007b0992067 P4D 80000007b0992067 PUD 7b62d4067 PMD 0
>> [ 3799.987654] Oops: 0002 [#1] PREEMPT SMP PTI
>> [ 3799.991831] Modules linked in: nf_nat_masquerade_ipv4 tun nfnetlink bridge stp llc nf_nat
>> nf_conntrack rpcrdma ib_ipoib rdma_ucm ib_ucm ib_umad rdma_cm ib_cm iw_cm sunrpc mlx5_ib ib
>> _uverbs ib_core coretemp kvm_intel kvm irqbypass intel_cstate intel_uncore intel_rapl_perf p
>> cspkr i2c_i801 shpchp wmi ipmi_si ipmi_devintf ipmi_msghandler acpi_pad sch_fq_codel i40e ml
>> x5_core hid_generic ixgbe igb devlink mdio ptp sd_mod i2c_algo_bit i2c_core pps_core [last u
>> nloaded: x_tables]
>> [ 3800.033472] CPU: 2 PID: 2006 Comm: xdpsock Not tainted 4.17.0-rc3-af_xdp03_ZC_rfc+ #155
>> [ 3800.041465] Hardware name: Supermicro Super Server/X10SRi-F, BIOS 2.0a 08/01/2016
>> [ 3800.048943] RIP: 0010:i40e_xmit_frame_ring+0xd4/0x1490 [i40e]
>> [ 3800.054683] RSP: 0018:ffffc9000407bcd0 EFLAGS: 00010293
>> [ 3800.059900] RAX: 0000000000000000 RBX: ffff88084f0fd200 RCX: 0000000000000000
>> [ 3800.067022] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffff8807b6e710c0
>> [ 3800.074148] RBP: ffff8807c6397800 R08: 00000000000000c0 R09: 0000000000000001
>> [ 3800.081270] R10: 0000000000000800 R11: 0000000000000010 R12: 0000000000000001
>> [ 3800.088396] R13: 0000000000000000 R14: 0000000000000001 R15: 000000000000003c
>> [ 3800.095520] FS: 00007f1d1e00bb80(0000) GS:ffff88087fc80000(0000) knlGS:0000000000000000
>> [ 3800.103597] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 3800.109335] CR2: 0000000000000008 CR3: 000000087d542001 CR4: 00000000003606e0
>> [ 3800.116458] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> [ 3800.123583] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>> [ 3800.130706] Call Trace:
>> [ 3800.133157] ? validate_xmit_skb.isra.116+0x1c/0x270
>> [ 3800.138118] dev_direct_xmit+0xec/0x1d0
>> [ 3800.141949] xsk_sendmsg+0x1f4/0x380
>> [ 3800.145521] sock_sendmsg+0x30/0x40
>> [ 3800.149005] __sys_sendto+0x10e/0x140
>> [ 3800.152662] ? __do_page_fault+0x283/0x500
>> [ 3800.156751] __x64_sys_sendto+0x24/0x30
>> [ 3800.160585] do_syscall_64+0x42/0xf0
>> [ 3800.164156] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> [ 3800.169204] RIP: 0033:0x7f1d1d9db430
>> [ 3800.172774] RSP: 002b:00007fffb7278610 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
>> [ 3800.180333] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1d1d9db430
>> [ 3800.187456] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
>> [ 3800.194582] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
>> [ 3800.201705] R10: 0000000000000040 R11: 0000000000000293 R12: 0000000000000000
>> [ 3800.208830] R13: 0000000000000000 R14: 0000000000755510 R15: 00007f1d0d3fc000
>> [ 3800.215953] Code: d0 0f 86 db 05 00 00 01 c8 0f b7 ca 29 c8 83 e8 01 39 c6 0f 8f ea 06 00 00 48 8b 45 28 48 8d 14 92 41 b9 01 00 00 00 4c 8d 2c d0 <49> 89 5d 08 8b 83 80 00 00 00 66 45 89 4d 14 41 89 45 10 0f b7
>> [ 3800.234798] RIP: i40e_xmit_frame_ring+0xd4/0x1490 [i40e] RSP: ffffc9000407bcd0
>> [ 3800.242005] CR2: 0000000000000008
>> [ 3800.245320] ---[ end trace f169e36f468e0c59 ]---
>> [ 3801.726719] Kernel panic - not syncing: Fatal exception in interrupt
>> [ 3801.733097] Kernel Offset: disabled
>> [ 3801.785836] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
>> [ 3801.793403] ------------[ cut here ]------------
>>
>> (gdb) list *(i40e_xmit_frame_ring)+0xd4
>> 0x2ccd4 is in i40e_xmit_frame_ring (drivers/net/ethernet/intel/i40e/i40e_txrx.c:4048).
>> warning: Source file is more recent than executable.
>> 4043 return NETDEV_TX_BUSY;
>> 4044 }
>> 4045
>> 4046 /* record the location of the first descriptor for this packet */
>> 4047 first = &tx_ring->tx_bi[tx_ring->next_to_use];
>> 4048 first->skb = skb;
>> 4049 first->bytecount = skb->len;
>> 4050 first->gso_segs = 1;
>> 4051
>> 4052 /* prepare the xmit flags */
>>
>>
>> (gdb) list *(xsk_sendmsg)+0x1f4
>> 0xffffffff81800c34 is in xsk_sendmsg (net/xdp/xsk.c:251).
>> warning: Source file is more recent than executable.
>> 246 skb_shinfo(skb)->destructor_arg = (void *)(long)id;
>> 247 skb->destructor = xsk_destruct_skb;
>> 248
>> 249 err = dev_direct_xmit(skb, xs->queue_id);
>> 250 /* Ignore NET_XMIT_CN as packet might have been sent */
>> 251 if (err == NET_XMIT_DROP || err == NETDEV_TX_BUSY) {
>> 252 err = -EAGAIN;
>> 253 /* SKB consumed by dev_direct_xmit() */
>> 254 goto out;
>> 255 }
>
Found it. Checked num_rx_queues in the xsk_bind code instead of
real_num_rx_queues. The code below will solve the problem. Will post a
proper patch for it tomorrow. Thanks Jesper for reporting this.
Appreciated.
/Magnus
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index ac97902..4b62a1e 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -391,7 +391,8 @@ static int xsk_bind(struct socket *sock, struct
sockaddr *addr, int addr_len)
goto out_unlock;
}
- if (sxdp->sxdp_queue_id >= dev->num_rx_queues) {
+ if ((xs->rx && sxdp->sxdp_queue_id >= dev->real_num_rx_queues) ||
+ (xs->tx && sxdp->sxdp_queue_id >= dev->real_num_tx_queues)) {
err = -EINVAL;
goto out_unlock;
}
^ permalink raw reply related
* Re: [pull request][net-next 00/16] Mellanox, mlx5e updates 2018-05-14
From: David Miller @ 2018-05-16 15:37 UTC (permalink / raw)
To: saeedm; +Cc: netdev
In-Reply-To: <20180514221934.20246-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Mon, 14 May 2018 15:19:18 -0700
> The following series contains misc updates for mlx5e netdevice driver.
> For more information please see tag log below.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Saeed.
^ permalink raw reply
* Re: i40e - Is i40e_force_link_state doing the right thing ?
From: Chaitanya Lala @ 2018-05-16 15:35 UTC (permalink / raw)
To: Stachura, Mariusz
Cc: netdev@vger.kernel.org, Williams, Mitch A, Bowers, AndrewX,
Kirsher, Jeffrey T
In-Reply-To: <1F86EBA5C8668B468CEE1C33B96E862B36905E19@IRSMSX104.ger.corp.intel.com>
Hi Mariusz, ...
On Wed, May 16, 2018 at 12:49 AM, Stachura, Mariusz
<mariusz.stachura@intel.com> wrote:
>> Hi Mariusz, ...
>>
>> On Tue, May 15, 2018 at 2:24 PM, Stachura, Mariusz <mariusz.stachura@intel.com> wrote:
>>> On Tue, May 15, 2018 at 1:15 PM, Chaitanya Lala <chaitanya.lala@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I am trying to bring up a Intel XL710 4x10G Intel card using the
>>>> latest mainline top-of-tree.
>>>> The problem is that "ifconfig up" and "ifconfig down" do not take
>>>> effect at the link state level.
>>>> I tracked the problem down to i40e_force_link_state() when it is
>>>> called from i40e_down().
>>>> It calls i40e_force_link_state with "is_up" == false. In-turn it
>>>> calls, i40e_aq_set_link_restart_an(hw, true, NULL).
>>>>
>>>> Should the second argument of i40e_aq_set_link_restart_an be "is_up"
>>>> vs the current "true"
>>>> i.e. i40e_aq_set_link_restart_an(hw, is_up, NULL). ? When I make this
>>>> change, the link state syncs-up with the interface administrative
>>>> state.
>>>>
>>>> Is this a bug ?
>>>>
>>>> Thanks,
>>>> Chaitanya
>>>
>>> Hello Chaitanya,
>>>
>>> i40e_down() calls i40e_force_link_state with "is_up" == false only if interface's private flag "link-down-on-close" is set. By default the link is left up for manageability and VF traffic, user can use this flag to power down the interface on the link level. Does that work for you?
>>> The command is:
>>> "ethtool --set-priv-flags IFNAME link-down-on-close on" and then
>>
>> This flag is _on_ in my setup and hencet i40e_force_link_state is being called with is_up == false in my setup. The problem is that irrespective of value of "is_up" flag, i40e_force_link_state invokes i40e_aq_set_link_restart_an with second argument (enable_link) as "true". So i40e_aq_set_link_restart_an is always trying to enable link even if is_up was false. Is that correct behavior ?
>>
>> I have pasted code with my annotations below marked with "//XXX".
>> (...)
>> Thanks,
>> Chaitanya
>
> Hey,
> i40e_aq_set_link_restart_an has second argument set to "true" intentionally, as I understand the "link-down-on-close" does not work for you, right? I will double check if this feature works for me and get back to you, thank you again.
That's correct. Even with the flag set, if-down does not result in a
link down for me. Thanks for checking!
-
Chaitanya
> --------------------------------------------------------------------
>
> Intel Technology Poland sp. z o.o.
> ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.
>
> Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
> przegladanie lub rozpowszechnianie jest zabronione.
> This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
> others is strictly prohibited.
^ permalink raw reply
* kernel BUG at lib/string.c:LINE! (4)
From: syzbot @ 2018-05-16 15:35 UTC (permalink / raw)
To: coreteam, davem, fw, horms, ja, kadlec, linux-kernel, lvs-devel,
netdev, netfilter-devel, pablo, syzkaller-bugs, wensong
Hello,
syzbot found the following crash on:
HEAD commit: 0b7d9978406f Merge branch 'Microsemi-Ocelot-Ethernet-switc..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16e91017800000
kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
dashboard link: https://syzkaller.appspot.com/bug?extid=aac887f77319868646df
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1665d637800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10517107800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+aac887f77319868646df@syzkaller.appspotmail.com
IPVS: Unknown mcast interface: veth1_to�a����
IPVS: Unknown mcast interface: veth1_to�a����
IPVS: Unknown mcast interface: veth1_to�a����
detected buffer overflow in strlen
------------[ cut here ]------------
kernel BUG at lib/string.c:1052!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 373 Comm: syz-executor936 Not tainted 4.17.0-rc4+ #45
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:fortify_panic+0x13/0x20 lib/string.c:1051
RSP: 0018:ffff8801c976f800 EFLAGS: 00010282
RAX: 0000000000000022 RBX: 0000000000000040 RCX: 0000000000000000
RDX: 0000000000000022 RSI: ffffffff8160f6f1 RDI: ffffed00392edef6
RBP: ffff8801c976f800 R08: ffff8801cf4c62c0 R09: ffffed003b5e4fb0
R10: ffffed003b5e4fb0 R11: ffff8801daf27d87 R12: ffff8801c976fa20
R13: ffff8801c976fae4 R14: ffff8801c976fae0 R15: 000000000000048b
FS: 00007fd99f75e700(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200001c0 CR3: 00000001d6843000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
strlen include/linux/string.h:270 [inline]
strlcpy include/linux/string.h:293 [inline]
do_ip_vs_set_ctl+0x31c/0x1d00 net/netfilter/ipvs/ip_vs_ctl.c:2388
nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
nf_setsockopt+0x7d/0xd0 net/netfilter/nf_sockopt.c:115
ip_setsockopt+0xd8/0xf0 net/ipv4/ip_sockglue.c:1253
udp_setsockopt+0x62/0xa0 net/ipv4/udp.c:2487
ipv6_setsockopt+0x149/0x170 net/ipv6/ipv6_sockglue.c:917
tcp_setsockopt+0x93/0xe0 net/ipv4/tcp.c:3057
sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3046
__sys_setsockopt+0x1bd/0x390 net/socket.c:1903
__do_sys_setsockopt net/socket.c:1914 [inline]
__se_sys_setsockopt net/socket.c:1911 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x447369
RSP: 002b:00007fd99f75dda8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00000000006e39e4 RCX: 0000000000447369
RDX: 000000000000048b RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000018 R09: 0000000000000000
R10: 00000000200001c0 R11: 0000000000000246 R12: 00000000006e39e0
R13: 75a1ff93f0896195 R14: 6f745f3168746576 R15: 0000000000000001
Code: 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b 48 89 df e8 d2 8f 48 fa eb
de 55 48 89 fe 48 c7 c7 60 65 64 88 48 89 e5 e8 91 dd f3 f9 <0f> 0b 90 90
90 90 90 90 90 90 90 90 90 55 48 89 e5 41 57 41 56
RIP: fortify_panic+0x13/0x20 lib/string.c:1051 RSP: ffff8801c976f800
---[ end trace 624046f2d9af7702 ]---
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* WARNING: kmalloc bug in map_get_next_key
From: syzbot @ 2018-05-16 15:35 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: c5c7d7f3c451 Merge branch 'bpf-sock-hashmap'
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13ec7877800000
kernel config: https://syzkaller.appspot.com/x/.config?x=10c4dc62055b68f5
dashboard link: https://syzkaller.appspot.com/bug?extid=e4566d29080e7f3460ff
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=12c35417800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=178c97f7800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e4566d29080e7f3460ff@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
WARNING: CPU: 0 PID: 4499 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70
mm/slab_common.c:996
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 4499 Comm: syz-executor050 Not tainted 4.17.0-rc3+ #9
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:kmalloc_slab+0x56/0x70 mm/slab_common.c:996
RSP: 0018:ffff8801d907fc58 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801aeecb280 RCX: ffffffff8185ebd7
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000ffffffe1
RBP: ffff8801d907fc58 R08: ffff8801adb5e1c0 R09: ffffed0035a84700
R10: ffffed0035a84700 R11: ffff8801ad423803 R12: ffff8801aeecb280
R13: 00000000fffffff4 R14: ffff8801ad891a00 R15: 00000000014200c0
__do_kmalloc mm/slab.c:3713 [inline]
__kmalloc+0x25/0x760 mm/slab.c:3727
kmalloc include/linux/slab.h:517 [inline]
map_get_next_key+0x24a/0x640 kernel/bpf/syscall.c:858
__do_sys_bpf kernel/bpf/syscall.c:2131 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2096 [inline]
__x64_sys_bpf+0x354/0x4f0 kernel/bpf/syscall.c:2096
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x43fd89
RSP: 002b:00007ffd6aab4668 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fd89
RDX: 0000000000000007 RSI: 0000000020000040 RDI: 0000000000000004
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 00000000004016b0
R13: 0000000000401740 R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* WARNING: kmalloc bug in memdup_user (3)
From: syzbot @ 2018-05-16 15:35 UTC (permalink / raw)
To: ast, daniel, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: c5c7d7f3c451 Merge branch 'bpf-sock-hashmap'
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1626ae37800000
kernel config: https://syzkaller.appspot.com/x/.config?x=10c4dc62055b68f5
dashboard link: https://syzkaller.appspot.com/bug?extid=0f92a17b0706231d0a09
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=126a5197800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1598c477800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0f92a17b0706231d0a09@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
WARNING: CPU: 0 PID: 4531 at mm/slab_common.c:996 kmalloc_slab+0x56/0x70
mm/slab_common.c:996
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 4531 Comm: syz-executor594 Not tainted 4.17.0-rc3+ #9
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
panic+0x22f/0x4de kernel/panic.c:184
__warn.cold.8+0x163/0x1b3 kernel/panic.c:536
report_bug+0x252/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x1de/0x490 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
RIP: 0010:kmalloc_slab+0x56/0x70 mm/slab_common.c:996
RSP: 0018:ffff8801ad4b7c48 EFLAGS: 00010246
RAX: 0000000000000000 RBX: fffffffffffffff4 RCX: ffffffff8185e678
RDX: ffffffff8185e6eb RSI: 0000000000000000 RDI: 00000000fffffffd
RBP: ffff8801ad4b7c48 R08: ffff8801adb3e2c0 R09: ffffed0035ba1f08
R10: ffffed0035ba1f08 R11: ffff8801add0f843 R12: 00000000fffffffd
R13: 0000000020000240 R14: 00000000ffffffff R15: 00000000014200c0
__do_kmalloc mm/slab.c:3713 [inline]
__kmalloc_track_caller+0x21/0x760 mm/slab.c:3733
memdup_user+0x2c/0xa0 mm/util.c:160
map_delete_elem+0x21b/0x4e0 kernel/bpf/syscall.c:796
__do_sys_bpf kernel/bpf/syscall.c:2128 [inline]
__se_sys_bpf kernel/bpf/syscall.c:2096 [inline]
__x64_sys_bpf+0x33f/0x4f0 kernel/bpf/syscall.c:2096
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x43fd89
RSP: 002b:00007ffe3ad9ad78 EFLAGS: 00000213 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fd89
RDX: 0000000000000010 RSI: 0000000020000000 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 00000000004016b0
R13: 0000000000401740 R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Vlad Buslov @ 2018-05-16 15:33 UTC (permalink / raw)
To: Roman Mashak
Cc: Jamal Hadi Salim, Linux Kernel Network Developers, David Miller,
Cong Wang, Jiri Pirko, pablo, kadlec, fw, ast, Daniel Borkmann,
Eric Dumazet, kliteyn
In-Reply-To: <CAHvchG=Kj9HNfzWfbqGA1rmmTh=C5PDPKJfDO6mUyXtA052hog@mail.gmail.com>
On Wed 16 May 2018 at 14:38, Roman Mashak <mrv@mojatatu.com> wrote:
> On Wed, May 16, 2018 at 2:43 AM, Vlad Buslov <vladbu@mellanox.com> wrote:
>>>>>> I'm trying to run tdc, but keep getting following error even on clean
>>>>>> branch without my patches:
>>>>>
>>>>> Vlad, not sure if you saw my email:
>>>>> Apply Roman's patch and try again
>>>>>
>>>>> https://marc.info/?l=linux-netdev&m=152639369112020&w=2
>>>>>
>>>>> cheers,
>>>>> jamal
>>>>
>>>> With patch applied I get following error:
>>>>
>>>> Test 7d50: Add skbmod action to set destination mac
>>>> exit: 255 0
>>>> dst MAC address <11:22:33:44:55:66>
>>>> RTNETLINK answers: No such file or directory
>>>> We have an error talking to the kernel
>>>>
>>>
>>> You may actually have broken something with your patches in this case.
>>
>> Results is for net-next without my patches.
>
> Do you have skbmod compiled in kernel or as a module?
Thanks, already figured out that default config has some actions
disabled.
Have more errors now. Everything related to ife:
Test 7682: Create valid ife encode action with mark and pass control
exit: 255 0
IFE type 0xED3E
RTNETLINK answers: No such file or directory
We have an error talking to the kernel
Test ef47: Create valid ife encode action with mark and pipe control
exit: 255 0
IFE type 0xED3E
RTNETLINK answers: No space left on device
We have an error talking to the kernel
Test df43: Create valid ife encode action with mark and continue control
exit: 255 0
IFE type 0xED3E
RTNETLINK answers: No space left on device
We have an error talking to the kernel
Test e4cf: Create valid ife encode action with mark and drop control
exit: 255 0
IFE type 0xED3E
RTNETLINK answers: No space left on device
We have an error talking to the kernel
Test ccba: Create valid ife encode action with mark and reclassify control
exit: 255 0
IFE type 0xED3E
RTNETLINK answers: No space left on device
We have an error talking to the kernel
Test a1cf: Create valid ife encode action with mark and jump control
exit: 255 0
IFE type 0xED3E
RTNETLINK answers: No space left on device
We have an error talking to the kernel
...
And problem with u32:
Test e9a3: Add u32 with source match
-----> prepare stage *** Could not execute: "$TC qdisc add dev $DEV1 ingress"
-----> prepare stage *** Error message: "Cannot find device "v0p1"
"
-----> prepare stage *** Aborting test run.
<_io.BufferedReader name=3> *** stdout ***
<_io.BufferedReader name=5> *** stderr ***
"-----> prepare stage" did not complete successfully
Exception <class '__main__.PluginMgrTestFail'> ('setup', None, '"-----> prepare stage" did not complete successfully') (caught in test_runner, running test 238 e9a3 Add u32 with source match stage setup)
---------------
traceback
File "./tdc.py", line 293, in test_runner
tap += run_one_test(pm, args, index, tidx)
File "./tdc.py", line 192, in run_one_test
prepare_env(args, pm, 'setup', "-----> prepare stage", tidx["setup"])
File "./tdc.py", line 177, in prepare_env
'"{}" did not complete successfully'.format(prefix))
---------------
---------------
Any suggestions regarding these errors?
Thanks,
Vlad
^ permalink raw reply
* Re: [PATCH net-next 00/10] Misc. Bug Fixes and clean-ups for HNS3 Driver
From: David Miller @ 2018-05-16 15:33 UTC (permalink / raw)
To: salil.mehta
Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
linuxarm
In-Reply-To: <20180515182014.42196-1-salil.mehta@huawei.com>
From: Salil Mehta <salil.mehta@huawei.com>
Date: Tue, 15 May 2018 19:20:04 +0100
> This patch-set mainly introduces various bug fixes, cleanups and one
> very small enhancement to existing HN3 driver code.
Series applied, thank you.
^ permalink raw reply
* INFO: rcu detected stall in ip_route_output_key_hash
From: syzbot @ 2018-05-16 15:29 UTC (permalink / raw)
To: davem, kuznet, linux-kernel, netdev, syzkaller-bugs, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 0b7d9978406f Merge branch 'Microsemi-Ocelot-Ethernet-switc..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1138c477800000
kernel config: https://syzkaller.appspot.com/x/.config?x=b632d8e2c2ab2c1
dashboard link: https://syzkaller.appspot.com/bug?extid=769a7ccbbb4b5074f125
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+769a7ccbbb4b5074f125@syzkaller.appspotmail.com
netlink: 4 bytes leftover after parsing attributes in process
`syz-executor2'.
random: crng init done
INFO: rcu_sched self-detected stall on CPU
1-...!: (121515 ticks this GP) idle=e7e/1/4611686018427387908
softirq=31362/31362 fqs=7
(t=125000 jiffies g=16439 c=16438 q=668508)
rcu_sched kthread starved for 124958 jiffies! g16439 c16438 f0x2
RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
RCU grace-period kthread stack dump:
rcu_sched R running task 23768 9 2 0x80000000
Call Trace:
context_switch kernel/sched/core.c:2848 [inline]
__schedule+0x801/0x1e30 kernel/sched/core.c:3490
schedule+0xef/0x430 kernel/sched/core.c:3549
schedule_timeout+0x138/0x240 kernel/time/timer.c:1801
rcu_gp_kthread+0x6b5/0x1940 kernel/rcu/tree.c:2231
kthread+0x345/0x410 kernel/kthread.c:238
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
NMI backtrace for cpu 1
CPU: 1 PID: 4488 Comm: syz-fuzzer Not tainted 4.17.0-rc4+ #45
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
nmi_cpu_backtrace.cold.4+0x19/0xce lib/nmi_backtrace.c:103
nmi_trigger_cpumask_backtrace+0x151/0x192 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_single_cpu_backtrace include/linux/nmi.h:156 [inline]
rcu_dump_cpu_stacks+0x175/0x1c2 kernel/rcu/tree.c:1376
print_cpu_stall kernel/rcu/tree.c:1525 [inline]
check_cpu_stall.isra.61.cold.80+0x36c/0x59a kernel/rcu/tree.c:1593
__rcu_pending kernel/rcu/tree.c:3356 [inline]
rcu_pending kernel/rcu/tree.c:3401 [inline]
rcu_check_callbacks+0x21b/0xad0 kernel/rcu/tree.c:2763
update_process_times+0x2d/0x70 kernel/time/timer.c:1636
tick_sched_handle+0x9f/0x180 kernel/time/tick-sched.c:164
tick_sched_timer+0x45/0x130 kernel/time/tick-sched.c:1274
__run_hrtimer kernel/time/hrtimer.c:1398 [inline]
__hrtimer_run_queues+0x3e3/0x10a0 kernel/time/hrtimer.c:1460
hrtimer_interrupt+0x2f3/0x750 kernel/time/hrtimer.c:1518
local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1025 [inline]
smp_apic_timer_interrupt+0x15d/0x710 arch/x86/kernel/apic/apic.c:1050
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
RIP: 0010:rcu_is_watching+0x6/0x140 kernel/rcu/tree.c:1071
RSP: 0000:ffff8801daf06620 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13
RAX: ffff8801ad526240 RBX: 0000000000000000 RCX: ffffffff86444456
RDX: 0000000000000100 RSI: ffffffff864444b8 RDI: 0000000000000001
RBP: ffff8801daf06628 R08: ffff8801ad526240 R09: 0000000000000002
R10: ffff8801ad526240 R11: 0000000000000000 R12: 1ffff1003b5e0cca
R13: ffff88008ff1a100 R14: 0000000000000000 R15: ffff8801daf066d0
rcu_read_unlock include/linux/rcupdate.h:684 [inline]
ip_route_output_key_hash+0x2cd/0x390 net/ipv4/route.c:2303
__ip_route_output_key include/net/route.h:124 [inline]
ip_route_output_flow+0x28/0xc0 net/ipv4/route.c:2557
ip_route_output_key include/net/route.h:134 [inline]
sctp_v4_get_dst+0x50e/0x17a0 net/sctp/protocol.c:447
sctp_transport_route+0x132/0x360 net/sctp/transport.c:303
sctp_packet_config+0x926/0xdd0 net/sctp/output.c:118
sctp_outq_select_transport+0x2bb/0x9c0 net/sctp/outqueue.c:877
sctp_outq_flush_ctrl.constprop.12+0x2ad/0xe60 net/sctp/outqueue.c:911
sctp_outq_flush+0x2ef/0x3430 net/sctp/outqueue.c:1203
sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x596/0x7160 net/sctp/sm_sideeffect.c:1191
sctp_generate_heartbeat_event+0x218/0x450 net/sctp/sm_sideeffect.c:406
call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x79e/0xc50 kernel/time/timer.c:1666
run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
__do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
invoke_softirq kernel/softirq.c:365 [inline]
irq_exit+0x1d1/0x200 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:525 [inline]
smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
</IRQ>
RIP: 0033:0x40b55d
RSP: 002b:000000c424bedca8 EFLAGS: 00000293 ORIG_RAX: ffffffffffffff13
RAX: 000000c4244e5470 RBX: 000000004d36768c RCX: 0000000000000000
RDX: 000000c4244e5470 RSI: 000000000000ffff RDI: 0000000000000000
RBP: 000000c424bedcc0 R08: 0000000000000000 R09: 0000000000000000
R10: 00000000009466f2 R11: 0000000000000004 R12: 0000000000000000
R13: 0000000000000020 R14: 0000000000000013 R15: 0000000000000034
BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 125s!
BUG: workqueue lockup - pool cpus=0-1 flags=0x4 nice=0 stuck for 125s!
Showing busy workqueues and worker pools:
workqueue events: flags=0x0
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=3/256
in-flight: 2104:do_numa_crng_init
pending: drbg_async_seed, cache_reap
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=9/256
pending: defense_work_handler, defense_work_handler,
defense_work_handler, defense_work_handler, defense_work_handler,
defense_work_handler, check_corruption, vmstat_shepherd, cache_reap
workqueue events_power_efficient: flags=0x80
pwq 2: cpus=1 node=0 flags=0x0 nice=0 active=1/256
pending: do_cache_clean
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=2/256
pending: check_lifetime, gc_worker
workqueue writeback: flags=0x4e
pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/256
in-flight: 6:wb_workfn
workqueue ipv6_addrconf: flags=0x40008
pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1
pending: addrconf_verify_work
workqueue krdsd: flags=0xe000a
pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/1
in-flight: 43:rds_connect_worker
pool 2: cpus=1 node=0 flags=0x0 nice=0 hung=0s workers=4 idle: 24 1980 18
pool 4: cpus=0-1 flags=0x4 nice=0 hung=0s workers=7 idle: 22 8018 287 6751
89
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply
* Re: [PATCH 00/14] Modify action API for implementing lockless actions
From: Jamal Hadi Salim @ 2018-05-16 15:02 UTC (permalink / raw)
To: Roman Mashak, Vlad Buslov
Cc: Linux Kernel Network Developers, David Miller, Cong Wang,
Jiri Pirko, pablo, kadlec, fw, ast, Daniel Borkmann, Eric Dumazet,
kliteyn
In-Reply-To: <CAHvchG=Kj9HNfzWfbqGA1rmmTh=C5PDPKJfDO6mUyXtA052hog@mail.gmail.com>
On 16/05/18 10:38 AM, Roman Mashak wrote:
>>>
>>> You may actually have broken something with your patches in this case.
>>
>> Results is for net-next without my patches.
>
> Do you have skbmod compiled in kernel or as a module?
>
Also - suggestion is to use latest iproute2 which interprets
extended error information (instead of the classical
"We have an error talking to the kernel").
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next] net: ethoc: Remove useless test before clk_disable_unprepare
From: Tobias Klauser @ 2018-05-16 15:00 UTC (permalink / raw)
To: YueHaibing; +Cc: davem, netdev, linux-kernel
In-Reply-To: <20180516111822.26440-1-yuehaibing@huawei.com>
On 2018-05-16 at 13:18:22 +0200, YueHaibing <yuehaibing@huawei.com> wrote:
> clk_disable_unprepare() already checks that the clock pointer is valid.
> No need to test it before calling it.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Tobias Klauser <tklauser@distanz.ch>
^ permalink raw reply
* Re: [PATCH 12/14] net: sched: retry action check-insert on concurrent modification
From: Jiri Pirko @ 2018-05-16 14:55 UTC (permalink / raw)
To: Vlad Buslov
Cc: netdev, davem, jhs, xiyou.wangcong, pablo, kadlec, fw, ast,
daniel, edumazet, keescook, linux-kernel, netfilter-devel,
coreteam, kliteyn
In-Reply-To: <vbfsh6r1xsv.fsf@reg-r-vrt-018-180.mtr.labs.mlnx>
Wed, May 16, 2018 at 04:26:40PM CEST, vladbu@mellanox.com wrote:
>
>On Wed 16 May 2018 at 14:13, Jiri Pirko <jiri@resnulli.us> wrote:
>> Wed, May 16, 2018 at 03:52:20PM CEST, vladbu@mellanox.com wrote:
>>>
>>>On Wed 16 May 2018 at 13:21, Jiri Pirko <jiri@resnulli.us> wrote:
>>>> Wed, May 16, 2018 at 02:43:58PM CEST, vladbu@mellanox.com wrote:
>>>>>
>>>>>On Wed 16 May 2018 at 12:26, Jiri Pirko <jiri@resnulli.us> wrote:
>>>>>> Wed, May 16, 2018 at 01:55:06PM CEST, vladbu@mellanox.com wrote:
>>>>>>>
>>>>>>>On Wed 16 May 2018 at 09:59, Jiri Pirko <jiri@resnulli.us> wrote:
>>>>>>>> Mon, May 14, 2018 at 04:27:13PM CEST, vladbu@mellanox.com wrote:
>>>>>>>>>Retry check-insert sequence in action init functions if action with same
>>>>>>>>>index was inserted concurrently.
>>>>>>>>>
>>>>>>>>>Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
>>>>>>>>>---
>>>>>>>>> net/sched/act_bpf.c | 8 +++++++-
>>>>>>>>> net/sched/act_connmark.c | 8 +++++++-
>>>>>>>>> net/sched/act_csum.c | 8 +++++++-
>>>>>>>>> net/sched/act_gact.c | 8 +++++++-
>>>>>>>>> net/sched/act_ife.c | 8 +++++++-
>>>>>>>>> net/sched/act_ipt.c | 8 +++++++-
>>>>>>>>> net/sched/act_mirred.c | 8 +++++++-
>>>>>>>>> net/sched/act_nat.c | 8 +++++++-
>>>>>>>>> net/sched/act_pedit.c | 8 +++++++-
>>>>>>>>> net/sched/act_police.c | 9 ++++++++-
>>>>>>>>> net/sched/act_sample.c | 8 +++++++-
>>>>>>>>> net/sched/act_simple.c | 9 ++++++++-
>>>>>>>>> net/sched/act_skbedit.c | 8 +++++++-
>>>>>>>>> net/sched/act_skbmod.c | 8 +++++++-
>>>>>>>>> net/sched/act_tunnel_key.c | 9 ++++++++-
>>>>>>>>> net/sched/act_vlan.c | 9 ++++++++-
>>>>>>>>> 16 files changed, 116 insertions(+), 16 deletions(-)
>>>>>>>>>
>>>>>>>>>diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c
>>>>>>>>>index 5554bf7..7e20fdc 100644
>>>>>>>>>--- a/net/sched/act_bpf.c
>>>>>>>>>+++ b/net/sched/act_bpf.c
>>>>>>>>>@@ -299,10 +299,16 @@ static int tcf_bpf_init(struct net *net, struct nlattr *nla,
>>>>>>>>>
>>>>>>>>> parm = nla_data(tb[TCA_ACT_BPF_PARMS]);
>>>>>>>>>
>>>>>>>>>+replay:
>>>>>>>>> if (!tcf_idr_check(tn, parm->index, act, bind)) {
>>>>>>>>> ret = tcf_idr_create(tn, parm->index, est, act,
>>>>>>>>> &act_bpf_ops, bind, true);
>>>>>>>>>- if (ret < 0)
>>>>>>>>>+ /* Action with specified index was created concurrently.
>>>>>>>>>+ * Check again.
>>>>>>>>>+ */
>>>>>>>>>+ if (parm->index && ret == -ENOSPC)
>>>>>>>>>+ goto replay;
>>>>>>>>>+ else if (ret)
>>>>>>>>
>>>>>>>> Hmm, looks like you are doing the same/very similar thing in every act
>>>>>>>> code. I think it would make sense to introduce a helper function for
>>>>>>>> this purpose.
>>>>>>>
>>>>>>>This code uses goto so it can't be easily refactored into standalone
>>>>>>>function. Could you specify which part of this code you suggest to
>>>>>>>extract?
>>>>>>
>>>>>> Hmm, looking at the code, I think that what would help is to have a
>>>>>> helper that would atomically check if index exists and if not, it would
>>>>>> allocate one. Something like:
>>>>>>
>>>>>>
>>>>>> int tcf_idr_check_alloc(struct tc_action_net *tn, u32 *index,
>>>>>> struct tc_action **a, int bind)
>>>>>> {
>>>>>> struct tcf_idrinfo *idrinfo = tn->idrinfo;
>>>>>> struct tc_action *p;
>>>>>> int err;
>>>>>>
>>>>>> spin_lock(&idrinfo->lock);
>>>>>> if (*index) {
>>>>>> p = idr_find(&idrinfo->action_idr, *index);
>>>>>> if (p) {
>>>>>> if (bind)
>>>>>> p->tcfa_bindcnt++;
>>>>>> p->tcfa_refcnt++;
>>>>>> *a = p;
>>>>>> err = 0;
>>>>>> } else {
>>>>>> *a = NULL;
>>>>>> err = idr_alloc_u32(idr, NULL, index,
>>>>>> *index, GFP_ATOMIC);
>>>>>> }
>>>>>> } else {
>>>>>> *index = 1;
>>>>>> *a = NULL;
>>>>>> err = idr_alloc_u32(idr, NULL, index, UINT_MAX, GFP_ATOMIC);
>>>>>> }
>>>>>> spin_unlock(&idrinfo->lock);
>>>>>> return err;
>>>>>> }
>>>>>>
>>>>>> The act code would just check if "a" is NULL and if so, it would call
>>>>>> tcf_idr_create() with allocated index as arg.
>>>>>
>>>>>What about multiple actions that have arbitrary code between initial
>>>>>check and idr allocation that is currently inside tcf_idr_create()?
>>>>
>>>> Why it would be a problem to have them after the allocation?
>>>
>>>Lets look at mirred for exmple:
>>> exists = tcf_idr_check(tn, parm->index, a, bind);
>>> if (exists && bind)
>>> return 0;
>>>
>>> switch (parm->eaction) {
>>> case TCA_EGRESS_MIRROR:
>>> case TCA_EGRESS_REDIR:
>>> case TCA_INGRESS_REDIR:
>>> case TCA_INGRESS_MIRROR:
>>> break;
>>> default:
>>> if (exists)
>>> tcf_idr_release(*a, bind);
>>> NL_SET_ERR_MSG_MOD(extack, "Unknown mirred option");
>>> return -EINVAL;
>>> }
>>> if (parm->ifindex) {
>>> dev = __dev_get_by_index(net, parm->ifindex);
>>> if (dev == NULL) {
>>> if (exists)
>>> tcf_idr_release(*a, bind);
>>> return -ENODEV;
>>> }
>>> mac_header_xmit = dev_is_mac_header_xmit(dev);
>>> } else {
>>> dev = NULL;
>>> }
>>>
>>> if (!exists) {
>>> if (!dev) {
>>> NL_SET_ERR_MSG_MOD(extack, "Specified device does not exist");
>>> return -EINVAL;
>>> }
>>> ret = tcf_idr_create(tn, parm->index, est, a,
>>> &act_mirred_ops, bind, true);
>>> /* Action with specified index was created concurrently.
>>> * Check again.
>>> */
>>> if (parm->index && ret == -ENOSPC)
>>> goto replay;
>>> else if (ret)
>>> return ret;
>>>
>>>There are several returns and cleanup is only performed when action
>>>exists. So all code like that will have to be audited to also remove
>>>index from idr, otherwise idr handles leak on return.
>>
>> Yeah. You have to take care of the error path.
>>
>>
>>>
>>>>
>>>> There is one issue though with my draft. tcf_idr_insert() function
>>>> which actually assigns a "p" pointer to the idr index is called later on.
>>>> Until that happens, the idr_find() would return NULL even if the index
>>>> is actually allocated. We cannot assign "p" in tcf_idr_check_alloc()
>>>> because it is allocated only later on in tcf_idr_create(). But that is
>>>> resolvable by the following trick:
>>>>
>>>> int tcf_idr_check_alloc(struct tc_action_net *tn, u32 *index,
>>>> struct tc_action **a, int bind)
>>>> {
>>>> struct tcf_idrinfo *idrinfo = tn->idrinfo;
>>>> struct tc_action *p;
>>>> int err;
>>>>
>>>> again:
>>>> spin_lock(&idrinfo->lock);
>>>> if (*index) {
>>>> p = idr_find(&idrinfo->action_idr, *index);
>>>> if (IS_ERR(p)) {
>>>> /* This means that another process allocated
>>>> * index but did not assign the pointer yet.
>>>> */
>>>> spin_unlock(&idrinfo->lock);
>>>> goto again;
>>>> }
>>>> if (p) {
>>>> if (bind)
>>>> p->tcfa_bindcnt++;
>>>> p->tcfa_refcnt++;
>>>> *a = p;
>>>> err = 0;
>>>> } else {
>>>> *a = NULL;
>>>> err = idr_alloc_u32(idr, NULL, index,
>>>> *index, GFP_ATOMIC);
>>>> idr_replace(&idrinfo->action_idr,
>>>> ERR_PTR(-EBUSY), *index);
>>>> }
>>>> } else {
>>>> *index = 1;
>>>> *a = NULL;
>>>> err = idr_alloc_u32(idr, NULL, index, UINT_MAX, GFP_ATOMIC);
>>>> idr_replace(&idrinfo->action_idr, ERR_PTR(-EBUSY), *index);
>>>> }
>>>> spin_unlock(&idrinfo->lock);
>>>> return err;
>>>> }
>>>>
>>>
>>>So users of action idr that might perform concurrent lookups are also
>>>have to be changed to check for error pointers, that now can be inserted
>>>into idr? Seems like a complex change...
>>
>> You can just add a simple check into tcf_idr_lookup(). Where else?
>>
>
>To me it looks like we take something simple and already working, and
>make it complex to save few lines of code in action init...
Well it is not only about saving lines of code but also to avoid
duplications of code. And duplications lead to bugs. That's why I
believe that helper here is needed.
>
>Anyway, how should I do patch split for this?
>Patch to implement function you outlined and another one to modify all
>actions to use it(with all refactoring to not leak references)? Or patch
>per action is better approach?
If you do it per-action, you would end up with many patches. It is not
needed I believe.
^ permalink raw reply
* Re: [iproute2] Bug#898840: Latest update breaks ip6 default gateway cli api
From: Michal Kubecek @ 2018-05-16 14:53 UTC (permalink / raw)
To: netdev
Cc: Serhey Popovych, Stephen Hemminger, Hans van Kranenburg, 898840,
Luca Boccassi
In-Reply-To: <1526478144.23337.126.camel@debian.org>
On Wed, May 16, 2018 at 02:42:24PM +0100, Luca Boccassi wrote:
> Hans reported a regression in v4.16.0, ip route now requires -6 to be
> manually added when using v6 addresses while up to 4.15 it didn't, the
> commands quoted show the problem.
>
> Bisecting shows that the following commit from Serhey introduced the
> problem:
>
> 93fa12418dc6f5943692250244be303bb162175b
> utils: Always specify family and ->bytelen in get_prefix_1()
>
> Could you please have a look when you have a moment? It's very easy to
> reproduce, and it breaks existing scripts and so on.
Fixed already:
------------------------------------------------------------------------------
mike@unicorn:~/work/git/iproute2> git --no-pager log --grep 93fa12418dc6
commit d42c7891d26e4d5616a55aac9fe10813767fcf9c
Author: David Ahern <dsahern@gmail.com>
Date: Fri Apr 13 09:36:33 2018 -0700
utils: Do not reset family for default, any, all addresses
Thomas reported a change in behavior with respect to autodectecting
address families. Specifically, 'ip ro add default via fe80::1'
syntax was failing to treat fe80::1 as an IPv6 address as it did in
prior releases. The root causes appears to be a change in family when
the default keyword is parsed.
'default', 'any' and 'all' are relevant outside of AF_INET. Leave the
family arg as is for these when setting addr.
Fixes: 93fa12418dc6 ("utils: Always specify family and ->bytelen in get_prefix_1()")
Reported-by: Thomas Deutschmann <whissi@gentoo.org>
Signed-off-by: David Ahern <dsahern@gmail.com>
Cc: Serhey Popovych <serhe.popovych@gmail.com>
------------------------------------------------------------------------------
Michal Kubecek
^ permalink raw reply
* [PATCH 11/11] perf bpf: Fix NULL return handling in bpf__prepare_load()
From: Arnaldo Carvalho de Melo @ 2018-05-16 14:49 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users, YueHaibing,
Alexander Shishkin, Namhyung Kim, Peter Zijlstra, netdev,
Arnaldo Carvalho de Melo
In-Reply-To: <20180516144908.22212-1-acme@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
bpf_object__open()/bpf_object__open_buffer can return error pointer or
NULL, check the return values with IS_ERR_OR_NULL() in bpf__prepare_load
and bpf__prepare_load_buffer
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: netdev@vger.kernel.org
Link: https://lkml.kernel.org/n/tip-psf4xwc09n62al2cb9s33v9h@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/bpf-loader.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/bpf-loader.c b/tools/perf/util/bpf-loader.c
index af7ad814b2c3..cee658733e2c 100644
--- a/tools/perf/util/bpf-loader.c
+++ b/tools/perf/util/bpf-loader.c
@@ -66,7 +66,7 @@ bpf__prepare_load_buffer(void *obj_buf, size_t obj_buf_sz, const char *name)
}
obj = bpf_object__open_buffer(obj_buf, obj_buf_sz, name);
- if (IS_ERR(obj)) {
+ if (IS_ERR_OR_NULL(obj)) {
pr_debug("bpf: failed to load buffer\n");
return ERR_PTR(-EINVAL);
}
@@ -102,14 +102,14 @@ struct bpf_object *bpf__prepare_load(const char *filename, bool source)
pr_debug("bpf: successfull builtin compilation\n");
obj = bpf_object__open_buffer(obj_buf, obj_buf_sz, filename);
- if (!IS_ERR(obj) && llvm_param.dump_obj)
+ if (!IS_ERR_OR_NULL(obj) && llvm_param.dump_obj)
llvm__dump_obj(filename, obj_buf, obj_buf_sz);
free(obj_buf);
} else
obj = bpf_object__open(filename);
- if (IS_ERR(obj)) {
+ if (IS_ERR_OR_NULL(obj)) {
pr_debug("bpf: failed to load %s\n", filename);
return obj;
}
--
2.14.3
^ permalink raw reply related
* [GIT PULL 00/11] perf/core improvements and fixes
From: Arnaldo Carvalho de Melo @ 2018-05-16 14:48 UTC (permalink / raw)
To: Ingo Molnar
Cc: Clark Williams, linux-kernel, linux-perf-users,
Arnaldo Carvalho de Melo, Adrian Hunter, Agustin Vega-Frias,
Alexander Shishkin, Andi Kleen, Andy Lutomirski, Daniel Borkmann,
Dave Hansen, David Ahern, Ganapatrao Kulkarni, H . Peter Anvin,
Jin Yao, Jiri Olsa, Joerg Roedel, Kan Liang, Masami Hiramatsu,
Namhyung Kim <namhyun
Hi Ingo,
Please consider pulling, more to come as I go thru Adrian's x86
PTI series and the C++ support improvements to 'perf probe', from
Holger,
Best Regards,
- Arnaldo
Test results at the end of this message, as usual.
The following changes since commit 291c161f6c65530092903fbea58eb07a62b220ba:
Merge remote-tracking branch 'tip/perf/urgent' into perf/core (2018-05-15 10:30:17 -0300)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-4.18-20180516
for you to fetch changes up to 7a36a287de9fbb1ba906e70573d3f2315f7fd609:
perf bpf: Fix NULL return handling in bpf__prepare_load() (2018-05-16 10:01:55 -0300)
----------------------------------------------------------------
perf/core improvements and fixes:
- Add '-e intel_pt//u' test to the 'parse-events' 'perf test' entry,
to help avoiding regressions in the events parser such as one
that caused a revert in v4.17-rc (Arnaldo Carvalho de Melo)
- Fix NULL return handling in bpf__prepare_load() (YueHaibing)
- Warn about 'perf buildid-cache --purge-all' failures (Ravi Bangoria)
- Add infrastructure to help in writing eBPF C programs to be used
with '-e name.c' type events in tools such as 'record' and 'trace',
with headers for common constructs and an examples directory that
will get populated as we add more such helpers and the 'perf bpf'
branch that Jiri Olsa has been working on (Arnaldo Carvalho de Melo)
- Handle uncore event aliases in small groups properly (Kan Liang)
- Use the "_stest" symbol to identify the kernel map when loading kcore (Adrian Hunter)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
----------------------------------------------------------------
Adrian Hunter (1):
perf tools: Use the "_stest" symbol to identify the kernel map when loading kcore
Arnaldo Carvalho de Melo (7):
perf tests parse-events: Add intel_pt parse test
perf llvm-utils: Add bpf include path to clang command line
perf bpf: Add 'examples' directories
perf bpf: Add bpf.h to be used in eBPF proggies
perf bpf: Add kprobe example to catch 5s naps
perf bpf: Add license(NAME) helper
perf bpf: Add probe() helper to reduce kprobes boilerplate
Kan Liang (1):
perf parse-events: Handle uncore event aliases in small groups properly
Ravi Bangoria (1):
perf buildid-cache: Warn --purge-all failures
YueHaibing (1):
perf bpf: Fix NULL return handling in bpf__prepare_load()
tools/perf/Makefile.config | 14 ++++
tools/perf/Makefile.perf | 8 +++
tools/perf/builtin-buildid-cache.c | 8 ++-
tools/perf/examples/bpf/5sec.c | 49 ++++++++++++++
tools/perf/examples/bpf/empty.c | 3 +
tools/perf/include/bpf/bpf.h | 13 ++++
tools/perf/tests/parse-events.c | 13 ++++
tools/perf/util/Build | 2 +
tools/perf/util/bpf-loader.c | 6 +-
tools/perf/util/evsel.h | 1 +
tools/perf/util/llvm-utils.c | 19 ++++--
tools/perf/util/parse-events.c | 130 ++++++++++++++++++++++++++++++++++++-
tools/perf/util/parse-events.h | 7 +-
tools/perf/util/parse-events.y | 8 +--
tools/perf/util/symbol.c | 16 ++---
15 files changed, 270 insertions(+), 27 deletions(-)
create mode 100644 tools/perf/examples/bpf/5sec.c
create mode 100644 tools/perf/examples/bpf/empty.c
create mode 100644 tools/perf/include/bpf/bpf.h
Test results:
The first ones are container (docker) based builds of tools/perf with
and without libelf support. Where clang is available, it is also used
to build perf with/without libelf, and building with LIBCLANGLLVM=1
(built-in clang) with gcc and clang when clang and its devel libraries
are installed.
The objtool and samples/bpf/ builds are disabled now that I'm switching from
using the sources in a local volume to fetching them from a http server to
build it inside the container, to make it easier to build in a container cluster.
Those will come back later.
Several are cross builds, the ones with -x-ARCH and the android one, and those
may not have all the features built, due to lack of multi-arch devel packages,
available and being used so far on just a few, like
debian:experimental-x-{arm64,mipsel}.
The 'perf test' one will perform a variety of tests exercising
tools/perf/util/, tools/lib/{bpf,traceevent,etc}, as well as run perf commands
with a variety of command line event specifications to then intercept the
sys_perf_event syscall to check that the perf_event_attr fields are set up as
expected, among a variety of other unit tests.
Then there is the 'make -C tools/perf build-test' ones, that build tools/perf/
with a variety of feature sets, exercising the build with an incomplete set of
features as well as with a complete one. It is planned to have it run on each
of the containers mentioned above, using some container orchestration
infrastructure. Get in contact if interested in helping having this in place.
# dm
1 alpine:3.4 : Ok gcc (Alpine 5.3.0) 5.3.0
2 alpine:3.5 : Ok gcc (Alpine 6.2.1) 6.2.1 20160822
3 alpine:3.6 : Ok gcc (Alpine 6.3.0) 6.3.0
4 alpine:3.7 : Ok gcc (Alpine 6.4.0) 6.4.0
5 alpine:edge : Ok gcc (Alpine 6.4.0) 6.4.0
6 amazonlinux:1 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
7 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
8 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
9 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
10 centos:5 : Ok gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
11 centos:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
12 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
13 debian:7 : Ok gcc (Debian 4.7.2-5) 4.7.2
14 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u1) 4.9.2
15 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
16 debian:experimental : Ok gcc (Debian 7.3.0-18) 7.3.0
17 debian:experimental-x-arm64 : Ok aarch64-linux-gnu-gcc (Debian 7.3.0-18) 7.3.0
18 debian:experimental-x-mips : Ok mips-linux-gnu-gcc (Debian 7.3.0-18) 7.3.0
19 debian:experimental-x-mips64 : Ok mips64-linux-gnuabi64-gcc (Debian 7.3.0-18) 7.3.0
20 debian:experimental-x-mipsel : Ok mipsel-linux-gnu-gcc (Debian 7.3.0-18) 7.3.0
21 fedora:20 : Ok gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
22 fedora:21 : Ok gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
23 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
24 fedora:23 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
25 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
26 fedora:24-x-ARC-uClibc : Ok arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710
27 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
28 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2)
29 fedora:27 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
30 fedora:28 : Ok gcc (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)
31 fedora:rawhide : Ok gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)
32 gentoo-stage3-amd64:latest : Ok gcc (Gentoo 6.4.0-r1 p1.3) 6.4.0
33 mageia:5 : Ok gcc (GCC) 4.9.2
34 mageia:6 : Ok gcc (Mageia 5.5.0-1.mga6) 5.5.0
35 opensuse:42.1 : Ok gcc (SUSE Linux) 4.8.5
36 opensuse:42.2 : Ok gcc (SUSE Linux) 4.8.5
37 opensuse:42.3 : Ok gcc (SUSE Linux) 4.8.5
38 opensuse:tumbleweed : Ok gcc (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812]
39 oraclelinux:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18.0.7)
40 oraclelinux:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28.0.1)
41 ubuntu:12.04.5 : Ok gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
42 ubuntu:14.04.4 : Ok gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
43 ubuntu:14.04.4-x-linaro-arm64 : Ok aarch64-linux-gnu-gcc (Linaro GCC 5.5-2017.10) 5.5.0
44 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
45 ubuntu:16.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
46 ubuntu:16.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
47 ubuntu:16.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
48 ubuntu:16.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
49 ubuntu:16.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
50 ubuntu:16.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
51 ubuntu:16.10 : Ok gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
52 ubuntu:17.04 : Ok gcc (Ubuntu 6.3.0-12ubuntu2) 6.3.0 20170406
53 ubuntu:17.10 : Ok gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
54 ubuntu:18.04 : Ok gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
#
# uname -a
Linux jouet 4.17.0-rc5 #21 SMP Mon May 14 15:35:35 -03 2018 x86_64 x86_64 x86_64 GNU/Linux
# perf test
1: vmlinux symtab matches kallsyms : Ok
2: Detect openat syscall event : Ok
3: Detect openat syscall event on all cpus : Ok
4: Read samples using the mmap interface : Ok
5: Test data source output : Ok
6: Parse event definition strings : Ok
7: Simple expression parser : Ok
8: PERF_RECORD_* events & perf_sample fields : Ok
9: Parse perf pmu format : Ok
10: DSO data read : Ok
11: DSO data cache : Ok
12: DSO data reopen : Ok
13: Roundtrip evsel->name : Ok
14: Parse sched tracepoints fields : Ok
15: syscalls:sys_enter_openat event fields : Ok
16: Setup struct perf_event_attr : Ok
17: Match and link multiple hists : Ok
18: 'import perf' in python : Ok
19: Breakpoint overflow signal handler : Ok
20: Breakpoint overflow sampling : Ok
21: Breakpoint accounting : Ok
22: Number of exit events of a simple workload : Ok
23: Software clock events period values : Ok
24: Object code reading : Ok
25: Sample parsing : Ok
26: Use a dummy software event to keep tracking : Ok
27: Parse with no sample_id_all bit set : Ok
28: Filter hist entries : Ok
29: Lookup mmap thread : Ok
30: Share thread mg : Ok
31: Sort output of hist entries : Ok
32: Cumulate child hist entries : Ok
33: Track with sched_switch : Ok
34: Filter fds with revents mask in a fdarray : Ok
35: Add fd to a fdarray, making it autogrow : Ok
36: kmod_path__parse : Ok
37: Thread map : Ok
38: LLVM search and compile :
38.1: Basic BPF llvm compile : Ok
38.2: kbuild searching : Ok
38.3: Compile source for BPF prologue generation : Ok
38.4: Compile source for BPF relocation : Ok
39: Session topology : Ok
40: BPF filter :
40.1: Basic BPF filtering : Ok
40.2: BPF pinning : Ok
40.3: BPF prologue generation : Ok
40.4: BPF relocation checker : Ok
41: Synthesize thread map : Ok
42: Remove thread map : Ok
43: Synthesize cpu map : Ok
44: Synthesize stat config : Ok
45: Synthesize stat : Ok
46: Synthesize stat round : Ok
47: Synthesize attr update : Ok
48: Event times : Ok
49: Read backward ring buffer : Ok
50: Print cpu map : Ok
51: Probe SDT events : Ok
52: is_printable_array : Ok
53: Print bitmap : Ok
54: perf hooks : Ok
55: builtin clang support : Skip (not compiled in)
56: unit_number__scnprintf : Ok
57: mem2node : Ok
58: x86 rdpmc : Ok
59: Convert perf time to TSC : Ok
60: DWARF unwind : Ok
61: x86 instruction decoder - new instructions : Ok
62: Use vfs_getname probe to get syscall args filenames : Ok
63: Check open filename arg using perf trace + vfs_getname: Ok
64: probe libc's inet_pton & backtrace it with ping : Ok
65: Add vfs_getname probe to get syscall args filenames : Ok
#
$ make -C tools/perf build-test
make: Entering directory '/home/acme/git/perf/tools/perf'
- tarpkg: ./tests/perf-targz-src-pkg .
make_with_babeltrace_O: make LIBBABELTRACE=1
make_static_O: make LDFLAGS=-static
make_tags_O: make tags
make_install_O: make install
make_doc_O: make doc
make_no_libelf_O: make NO_LIBELF=1
make_no_libbpf_O: make NO_LIBBPF=1
make_no_demangle_O: make NO_DEMANGLE=1
make_clean_all_O: make clean all
make_no_slang_O: make NO_SLANG=1
make_no_scripts_O: make NO_LIBPYTHON=1 NO_LIBPERL=1
make_with_clangllvm_O: make LIBCLANGLLVM=1
make_no_newt_O: make NO_NEWT=1
make_no_libnuma_O: make NO_LIBNUMA=1
make_no_libdw_dwarf_unwind_O: make NO_LIBDW_DWARF_UNWIND=1
make_no_libbionic_O: make NO_LIBBIONIC=1
make_no_libperl_O: make NO_LIBPERL=1
make_no_libpython_O: make NO_LIBPYTHON=1
make_no_libunwind_O: make NO_LIBUNWIND=1
make_no_backtrace_O: make NO_BACKTRACE=1
make_install_prefix_slash_O: make install prefix=/tmp/krava/
make_debug_O: make DEBUG=1
make_util_map_o_O: make util/map.o
make_minimal_O: make NO_LIBPERL=1 NO_LIBPYTHON=1 NO_NEWT=1 NO_GTK2=1 NO_DEMANGLE=1 NO_LIBELF=1 NO_LIBUNWIND=1 NO_BACKTRACE=1 NO_LIBNUMA=1 NO_LIBAUDIT=1 NO_LIBBIONIC=1 NO_LIBDW_DWARF_UNWIND=1 NO_AUXTRACE=1 NO_LIBBPF=1 NO_LIBCRYPTO=1 NO_SDT=1 NO_JVMTI=1
make_install_prefix_O: make install prefix=/tmp/krava
make_pure_O: make
make_perf_o_O: make perf.o
make_help_O: make help
make_no_gtk2_O: make NO_GTK2=1
make_no_libaudit_O: make NO_LIBAUDIT=1
make_util_pmu_bison_o_O: make util/pmu-bison.o
make_no_ui_O: make NO_NEWT=1 NO_SLANG=1 NO_GTK2=1
make_install_bin_O: make install-bin
make_no_auxtrace_O: make NO_AUXTRACE=1
OK
make: Leaving directory '/home/acme/git/perf/tools/perf'
$
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox