* Re: [PATCHv2 bpf-next 08/11] selftests/bpf: Add tests for reference tracking
From: Joe Stringer @ 2018-09-26 22:31 UTC (permalink / raw)
To: daniel
Cc: Joe Stringer, ast, netdev, john fastabend, tgraf,
Martin KaFai Lau, Nitin Hande, mauricio.vasquez
In-Reply-To: <3bdb6449-41ce-ef1a-b845-c55f6d44775d@iogearbox.net>
On Mon, 24 Sep 2018 at 05:22, Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 09/21/2018 07:10 PM, Joe Stringer wrote:
> > reference tracking: leak potential reference
> > reference tracking: leak potential reference on stack
> > reference tracking: leak potential reference on stack 2
> > reference tracking: zero potential reference
> > reference tracking: copy and zero potential references
> > reference tracking: release reference without check
> > reference tracking: release reference
> > reference tracking: release reference twice
> > reference tracking: release reference twice inside branch
> > reference tracking: alloc, check, free in one subbranch
> > reference tracking: alloc, check, free in both subbranches
> > reference tracking in call: free reference in subprog
> > reference tracking in call: free reference in subprog and outside
> > reference tracking in call: alloc & leak reference in subprog
> > reference tracking in call: alloc in subprog, release outside
> > reference tracking in call: sk_ptr leak into caller stack
> > reference tracking in call: sk_ptr spill into caller stack
> >
> > Signed-off-by: Joe Stringer <joe@wand.net.nz>
> > Acked-by: Alexei Starovoitov <ast@kernel.org>
> > ---
> > tools/testing/selftests/bpf/test_verifier.c | 359 ++++++++++++++++++++
> > 1 file changed, 359 insertions(+)
>
> I think this here needs to have some more test cases that we current do not track but
> should in order to have better coverage. At minimum what comes to mind additionally:
>
> - verifier interaction with LD_ABS, LD_IND
> - verifier interaction with tail calls (e.g. try to leak socket, socket_or_null, etc,
> but should also have a positive test where we drop ref before tail call to show it
> works in combination)
> - Try to mangle a socket and socket_or_null pointer with ALU ops and pass it to helper
> - Try to access the socket data fields after we released its reference
> - Access socket member fields in general (I think not present right now)
> - Use direct packet access in combination with lookup helper (it's enabled
> via pkt_access = true in the helper, so we should also test for it here to make
> sure future changes don't break it)
Great suggestions, I think that the LD_ABS/LD_IND ones are good
candidates for the assembly-level tests here. For the remainder, I
plan to add them to the C cases. That'll be easier to review and
easier to understand if they ever get broken.
Regarding the direct packet access with lookup, that's already in this
series in the C verifier tests patch.
^ permalink raw reply
* [PATCH bpf-next 4/5] selftests/bpf: Use libbpf_attach_type_by_name in test_socket_cookie
From: Andrey Ignatov @ 2018-09-26 22:24 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team
In-Reply-To: <cover.1538000102.git.rdna@fb.com>
Use newly introduced libbpf_attach_type_by_name in test_socket_cookie
selftest.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/testing/selftests/bpf/test_socket_cookie.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_socket_cookie.c b/tools/testing/selftests/bpf/test_socket_cookie.c
index 68e108e4687a..b6c2c605d8c0 100644
--- a/tools/testing/selftests/bpf/test_socket_cookie.c
+++ b/tools/testing/selftests/bpf/test_socket_cookie.c
@@ -158,11 +158,7 @@ static int run_test(int cgfd)
bpf_object__for_each_program(prog, pobj) {
prog_name = bpf_program__title(prog, /*needs_copy*/ false);
- if (strcmp(prog_name, "cgroup/connect6") == 0) {
- attach_type = BPF_CGROUP_INET6_CONNECT;
- } else if (strcmp(prog_name, "sockops") == 0) {
- attach_type = BPF_CGROUP_SOCK_OPS;
- } else {
+ if (libbpf_attach_type_by_name(prog_name, &attach_type)) {
log_err("Unexpected prog: %s", prog_name);
goto err;
}
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 5/5] selftests/bpf: Test libbpf_{prog,attach}_type_by_name
From: Andrey Ignatov @ 2018-09-26 22:24 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team
In-Reply-To: <cover.1538000102.git.rdna@fb.com>
Add selftest for libbpf functions libbpf_prog_type_by_name and
libbpf_attach_type_by_name.
Example of output:
% ./tools/testing/selftests/bpf/test_section_names
Summary: 35 PASSED, 0 FAILED
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/testing/selftests/bpf/Makefile | 2 +-
.../selftests/bpf/test_section_names.c | 208 ++++++++++++++++++
2 files changed, 209 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/bpf/test_section_names.c
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index fd3851d5c079..059d64a0f897 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -23,7 +23,7 @@ $(TEST_CUSTOM_PROGS): $(OUTPUT)/%: %.c
TEST_GEN_PROGS = test_verifier test_tag test_maps test_lru_map test_lpm_map test_progs \
test_align test_verifier_log test_dev_cgroup test_tcpbpf_user \
test_sock test_btf test_sockmap test_lirc_mode2_user get_cgroup_id_user \
- test_socket_cookie test_cgroup_storage test_select_reuseport
+ test_socket_cookie test_cgroup_storage test_select_reuseport test_section_names
TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o test_tcp_estats.o test_obj_id.o \
test_pkt_md_access.o test_xdp_redirect.o test_xdp_meta.o sockmap_parse_prog.o \
diff --git a/tools/testing/selftests/bpf/test_section_names.c b/tools/testing/selftests/bpf/test_section_names.c
new file mode 100644
index 000000000000..7c4f41572b1c
--- /dev/null
+++ b/tools/testing/selftests/bpf/test_section_names.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2018 Facebook
+
+#include <err.h>
+#include <bpf/libbpf.h>
+
+#include "bpf_util.h"
+
+struct sec_name_test {
+ const char sec_name[32];
+ struct {
+ int rc;
+ enum bpf_prog_type prog_type;
+ enum bpf_attach_type expected_attach_type;
+ } expected_load;
+ struct {
+ int rc;
+ enum bpf_attach_type attach_type;
+ } expected_attach;
+};
+
+static struct sec_name_test tests[] = {
+ {"InvAliD", {-EINVAL, 0, 0}, {-EINVAL, 0} },
+ {"cgroup", {-EINVAL, 0, 0}, {-EINVAL, 0} },
+ {"socket", {0, BPF_PROG_TYPE_SOCKET_FILTER, 0}, {-EINVAL, 0} },
+ {"kprobe/", {0, BPF_PROG_TYPE_KPROBE, 0}, {-EINVAL, 0} },
+ {"kretprobe/", {0, BPF_PROG_TYPE_KPROBE, 0}, {-EINVAL, 0} },
+ {"classifier", {0, BPF_PROG_TYPE_SCHED_CLS, 0}, {-EINVAL, 0} },
+ {"action", {0, BPF_PROG_TYPE_SCHED_ACT, 0}, {-EINVAL, 0} },
+ {"tracepoint/", {0, BPF_PROG_TYPE_TRACEPOINT, 0}, {-EINVAL, 0} },
+ {
+ "raw_tracepoint/",
+ {0, BPF_PROG_TYPE_RAW_TRACEPOINT, 0},
+ {-EINVAL, 0},
+ },
+ {"xdp", {0, BPF_PROG_TYPE_XDP, 0}, {-EINVAL, 0} },
+ {"perf_event", {0, BPF_PROG_TYPE_PERF_EVENT, 0}, {-EINVAL, 0} },
+ {"lwt_in", {0, BPF_PROG_TYPE_LWT_IN, 0}, {-EINVAL, 0} },
+ {"lwt_out", {0, BPF_PROG_TYPE_LWT_OUT, 0}, {-EINVAL, 0} },
+ {"lwt_xmit", {0, BPF_PROG_TYPE_LWT_XMIT, 0}, {-EINVAL, 0} },
+ {"lwt_seg6local", {0, BPF_PROG_TYPE_LWT_SEG6LOCAL, 0}, {-EINVAL, 0} },
+ {
+ "cgroup_skb/ingress",
+ {0, BPF_PROG_TYPE_CGROUP_SKB, 0},
+ {0, BPF_CGROUP_INET_INGRESS},
+ },
+ {
+ "cgroup_skb/egress",
+ {0, BPF_PROG_TYPE_CGROUP_SKB, 0},
+ {0, BPF_CGROUP_INET_EGRESS},
+ },
+ {"cgroup/skb", {0, BPF_PROG_TYPE_CGROUP_SKB, 0}, {-EINVAL, 0} },
+ {
+ "cgroup/sock",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK, 0},
+ {0, BPF_CGROUP_INET_SOCK_CREATE},
+ },
+ {
+ "cgroup/post_bind4",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK, BPF_CGROUP_INET4_POST_BIND},
+ {0, BPF_CGROUP_INET4_POST_BIND},
+ },
+ {
+ "cgroup/post_bind6",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK, BPF_CGROUP_INET6_POST_BIND},
+ {0, BPF_CGROUP_INET6_POST_BIND},
+ },
+ {
+ "cgroup/dev",
+ {0, BPF_PROG_TYPE_CGROUP_DEVICE, 0},
+ {0, BPF_CGROUP_DEVICE},
+ },
+ {"sockops", {0, BPF_PROG_TYPE_SOCK_OPS, 0}, {0, BPF_CGROUP_SOCK_OPS} },
+ {
+ "sk_skb/stream_parser",
+ {0, BPF_PROG_TYPE_SK_SKB, 0},
+ {0, BPF_SK_SKB_STREAM_PARSER},
+ },
+ {
+ "sk_skb/stream_verdict",
+ {0, BPF_PROG_TYPE_SK_SKB, 0},
+ {0, BPF_SK_SKB_STREAM_VERDICT},
+ },
+ {"sk_skb", {0, BPF_PROG_TYPE_SK_SKB, 0}, {-EINVAL, 0} },
+ {"sk_msg", {0, BPF_PROG_TYPE_SK_MSG, 0}, {0, BPF_SK_MSG_VERDICT} },
+ {"lirc_mode2", {0, BPF_PROG_TYPE_LIRC_MODE2, 0}, {0, BPF_LIRC_MODE2} },
+ {
+ "flow_dissector",
+ {0, BPF_PROG_TYPE_FLOW_DISSECTOR, 0},
+ {0, BPF_FLOW_DISSECTOR},
+ },
+ {
+ "cgroup/bind4",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_CGROUP_INET4_BIND},
+ {0, BPF_CGROUP_INET4_BIND},
+ },
+ {
+ "cgroup/bind6",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_CGROUP_INET6_BIND},
+ {0, BPF_CGROUP_INET6_BIND},
+ },
+ {
+ "cgroup/connect4",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_CGROUP_INET4_CONNECT},
+ {0, BPF_CGROUP_INET4_CONNECT},
+ },
+ {
+ "cgroup/connect6",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_CGROUP_INET6_CONNECT},
+ {0, BPF_CGROUP_INET6_CONNECT},
+ },
+ {
+ "cgroup/sendmsg4",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_CGROUP_UDP4_SENDMSG},
+ {0, BPF_CGROUP_UDP4_SENDMSG},
+ },
+ {
+ "cgroup/sendmsg6",
+ {0, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, BPF_CGROUP_UDP6_SENDMSG},
+ {0, BPF_CGROUP_UDP6_SENDMSG},
+ },
+};
+
+static int test_prog_type_by_name(const struct sec_name_test *test)
+{
+ enum bpf_attach_type expected_attach_type;
+ enum bpf_prog_type prog_type;
+ int rc;
+
+ rc = libbpf_prog_type_by_name(test->sec_name, &prog_type,
+ &expected_attach_type);
+
+ if (rc != test->expected_load.rc) {
+ warnx("prog: unexpected rc=%d for %s", rc, test->sec_name);
+ return -1;
+ }
+
+ if (rc)
+ return 0;
+
+ if (prog_type != test->expected_load.prog_type) {
+ warnx("prog: unexpected prog_type=%d for %s", prog_type,
+ test->sec_name);
+ return -1;
+ }
+
+ if (expected_attach_type != test->expected_load.expected_attach_type) {
+ warnx("prog: unexpected expected_attach_type=%d for %s",
+ expected_attach_type, test->sec_name);
+ return -1;
+ }
+
+ return 0;
+}
+
+static int test_attach_type_by_name(const struct sec_name_test *test)
+{
+ enum bpf_attach_type attach_type;
+ int rc;
+
+ rc = libbpf_attach_type_by_name(test->sec_name, &attach_type);
+
+ if (rc != test->expected_attach.rc) {
+ warnx("attach: unexpected rc=%d for %s", rc, test->sec_name);
+ return -1;
+ }
+
+ if (rc)
+ return 0;
+
+ if (attach_type != test->expected_attach.attach_type) {
+ warnx("attach: unexpected attach_type=%d for %s", attach_type,
+ test->sec_name);
+ return -1;
+ }
+
+ return 0;
+}
+
+static int run_test_case(const struct sec_name_test *test)
+{
+ if (test_prog_type_by_name(test))
+ return -1;
+ if (test_attach_type_by_name(test))
+ return -1;
+ return 0;
+}
+
+static int run_tests(void)
+{
+ int passes = 0;
+ int fails = 0;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(tests); ++i) {
+ if (run_test_case(&tests[i]))
+ ++fails;
+ else
+ ++passes;
+ }
+ printf("Summary: %d PASSED, %d FAILED\n", passes, fails);
+ return fails ? -1 : 0;
+}
+
+int main(int argc, char **argv)
+{
+ return run_tests();
+}
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 1/5] libbpf: Introduce libbpf_attach_type_by_name
From: Andrey Ignatov @ 2018-09-26 22:24 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team
In-Reply-To: <cover.1538000102.git.rdna@fb.com>
There is a common use-case when ELF object contains multiple BPF
programs and every program has its own section name. If it's cgroup-bpf
then programs have to be 1) loaded and 2) attached to a cgroup.
It's convenient to have information necessary to load BPF program
together with program itself. This is where section name works fine in
conjunction with libbpf_prog_type_by_name that identifies prog_type and
expected_attach_type and these can be used with BPF_PROG_LOAD.
But there is currently no way to identify attach_type by section name
and it leads to messy code in user space that reinvents guessing logic
every time it has to identify attach type to use with BPF_PROG_ATTACH.
The patch introduces libbpf_attach_type_by_name that guesses attach type
by section name if a program can be attached.
The difference between expected_attach_type provided by
libbpf_prog_type_by_name and attach_type provided by
libbpf_attach_type_by_name is the former is used at BPF_PROG_LOAD time
and can be zero if a program of prog_type X has only one corresponding
attach type Y whether the latter provides specific attach type to use
with BPF_PROG_ATTACH.
No new section names were added to section_names array. Only existing
ones were reorganized and attach_type was added where appropriate.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/lib/bpf/libbpf.c | 121 ++++++++++++++++++++++++++++-------------
tools/lib/bpf/libbpf.h | 2 +
2 files changed, 84 insertions(+), 39 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 4f8d43ae20d2..59e589a64d5c 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -2085,58 +2085,82 @@ void bpf_program__set_expected_attach_type(struct bpf_program *prog,
prog->expected_attach_type = type;
}
-#define BPF_PROG_SEC_FULL(string, ptype, atype) \
- { string, sizeof(string) - 1, ptype, atype }
+#define BPF_PROG_SEC_IMPL(string, ptype, eatype, atype) \
+ { string, sizeof(string) - 1, ptype, eatype, atype }
-#define BPF_PROG_SEC(string, ptype) BPF_PROG_SEC_FULL(string, ptype, 0)
+/* Programs that can NOT be attached. */
+#define BPF_PROG_SEC(string, ptype) BPF_PROG_SEC_IMPL(string, ptype, 0, -EINVAL)
-#define BPF_S_PROG_SEC(string, ptype) \
- BPF_PROG_SEC_FULL(string, BPF_PROG_TYPE_CGROUP_SOCK, ptype)
+/* Programs that can be attached. */
+#define BPF_APROG_SEC(string, ptype, atype) \
+ BPF_PROG_SEC_IMPL(string, ptype, 0, atype)
-#define BPF_SA_PROG_SEC(string, ptype) \
- BPF_PROG_SEC_FULL(string, BPF_PROG_TYPE_CGROUP_SOCK_ADDR, ptype)
+/* Programs that must specify expected attach type at load time. */
+#define BPF_EAPROG_SEC(string, ptype, eatype) \
+ BPF_PROG_SEC_IMPL(string, ptype, eatype, eatype)
+
+/* Programs that can be attached but attach type can't be identified by section
+ * name. Kept for backward compatibility.
+ */
+#define BPF_APROG_COMPAT(string, ptype) BPF_PROG_SEC(string, ptype)
static const struct {
const char *sec;
size_t len;
enum bpf_prog_type prog_type;
enum bpf_attach_type expected_attach_type;
+ enum bpf_attach_type attach_type;
} section_names[] = {
- BPF_PROG_SEC("socket", BPF_PROG_TYPE_SOCKET_FILTER),
- BPF_PROG_SEC("kprobe/", BPF_PROG_TYPE_KPROBE),
- BPF_PROG_SEC("kretprobe/", BPF_PROG_TYPE_KPROBE),
- BPF_PROG_SEC("classifier", BPF_PROG_TYPE_SCHED_CLS),
- BPF_PROG_SEC("action", BPF_PROG_TYPE_SCHED_ACT),
- BPF_PROG_SEC("tracepoint/", BPF_PROG_TYPE_TRACEPOINT),
- BPF_PROG_SEC("raw_tracepoint/", BPF_PROG_TYPE_RAW_TRACEPOINT),
- BPF_PROG_SEC("xdp", BPF_PROG_TYPE_XDP),
- BPF_PROG_SEC("perf_event", BPF_PROG_TYPE_PERF_EVENT),
- BPF_PROG_SEC("cgroup/skb", BPF_PROG_TYPE_CGROUP_SKB),
- BPF_PROG_SEC("cgroup/sock", BPF_PROG_TYPE_CGROUP_SOCK),
- BPF_PROG_SEC("cgroup/dev", BPF_PROG_TYPE_CGROUP_DEVICE),
- BPF_PROG_SEC("lwt_in", BPF_PROG_TYPE_LWT_IN),
- BPF_PROG_SEC("lwt_out", BPF_PROG_TYPE_LWT_OUT),
- BPF_PROG_SEC("lwt_xmit", BPF_PROG_TYPE_LWT_XMIT),
- BPF_PROG_SEC("lwt_seg6local", BPF_PROG_TYPE_LWT_SEG6LOCAL),
- BPF_PROG_SEC("sockops", BPF_PROG_TYPE_SOCK_OPS),
- BPF_PROG_SEC("sk_skb", BPF_PROG_TYPE_SK_SKB),
- BPF_PROG_SEC("sk_msg", BPF_PROG_TYPE_SK_MSG),
- BPF_PROG_SEC("lirc_mode2", BPF_PROG_TYPE_LIRC_MODE2),
- BPF_PROG_SEC("flow_dissector", BPF_PROG_TYPE_FLOW_DISSECTOR),
- BPF_SA_PROG_SEC("cgroup/bind4", BPF_CGROUP_INET4_BIND),
- BPF_SA_PROG_SEC("cgroup/bind6", BPF_CGROUP_INET6_BIND),
- BPF_SA_PROG_SEC("cgroup/connect4", BPF_CGROUP_INET4_CONNECT),
- BPF_SA_PROG_SEC("cgroup/connect6", BPF_CGROUP_INET6_CONNECT),
- BPF_SA_PROG_SEC("cgroup/sendmsg4", BPF_CGROUP_UDP4_SENDMSG),
- BPF_SA_PROG_SEC("cgroup/sendmsg6", BPF_CGROUP_UDP6_SENDMSG),
- BPF_S_PROG_SEC("cgroup/post_bind4", BPF_CGROUP_INET4_POST_BIND),
- BPF_S_PROG_SEC("cgroup/post_bind6", BPF_CGROUP_INET6_POST_BIND),
+ BPF_PROG_SEC("socket", BPF_PROG_TYPE_SOCKET_FILTER),
+ BPF_PROG_SEC("kprobe/", BPF_PROG_TYPE_KPROBE),
+ BPF_PROG_SEC("kretprobe/", BPF_PROG_TYPE_KPROBE),
+ BPF_PROG_SEC("classifier", BPF_PROG_TYPE_SCHED_CLS),
+ BPF_PROG_SEC("action", BPF_PROG_TYPE_SCHED_ACT),
+ BPF_PROG_SEC("tracepoint/", BPF_PROG_TYPE_TRACEPOINT),
+ BPF_PROG_SEC("raw_tracepoint/", BPF_PROG_TYPE_RAW_TRACEPOINT),
+ BPF_PROG_SEC("xdp", BPF_PROG_TYPE_XDP),
+ BPF_PROG_SEC("perf_event", BPF_PROG_TYPE_PERF_EVENT),
+ BPF_PROG_SEC("lwt_in", BPF_PROG_TYPE_LWT_IN),
+ BPF_PROG_SEC("lwt_out", BPF_PROG_TYPE_LWT_OUT),
+ BPF_PROG_SEC("lwt_xmit", BPF_PROG_TYPE_LWT_XMIT),
+ BPF_PROG_SEC("lwt_seg6local", BPF_PROG_TYPE_LWT_SEG6LOCAL),
+ BPF_APROG_COMPAT("cgroup/skb", BPF_PROG_TYPE_CGROUP_SKB),
+ BPF_APROG_SEC("cgroup/sock", BPF_PROG_TYPE_CGROUP_SOCK,
+ BPF_CGROUP_INET_SOCK_CREATE),
+ BPF_EAPROG_SEC("cgroup/post_bind4", BPF_PROG_TYPE_CGROUP_SOCK,
+ BPF_CGROUP_INET4_POST_BIND),
+ BPF_EAPROG_SEC("cgroup/post_bind6", BPF_PROG_TYPE_CGROUP_SOCK,
+ BPF_CGROUP_INET6_POST_BIND),
+ BPF_APROG_SEC("cgroup/dev", BPF_PROG_TYPE_CGROUP_DEVICE,
+ BPF_CGROUP_DEVICE),
+ BPF_APROG_SEC("sockops", BPF_PROG_TYPE_SOCK_OPS,
+ BPF_CGROUP_SOCK_OPS),
+ BPF_APROG_COMPAT("sk_skb", BPF_PROG_TYPE_SK_SKB),
+ BPF_APROG_SEC("sk_msg", BPF_PROG_TYPE_SK_MSG,
+ BPF_SK_MSG_VERDICT),
+ BPF_APROG_SEC("lirc_mode2", BPF_PROG_TYPE_LIRC_MODE2,
+ BPF_LIRC_MODE2),
+ BPF_APROG_SEC("flow_dissector", BPF_PROG_TYPE_FLOW_DISSECTOR,
+ BPF_FLOW_DISSECTOR),
+ BPF_EAPROG_SEC("cgroup/bind4", BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+ BPF_CGROUP_INET4_BIND),
+ BPF_EAPROG_SEC("cgroup/bind6", BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+ BPF_CGROUP_INET6_BIND),
+ BPF_EAPROG_SEC("cgroup/connect4", BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+ BPF_CGROUP_INET4_CONNECT),
+ BPF_EAPROG_SEC("cgroup/connect6", BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+ BPF_CGROUP_INET6_CONNECT),
+ BPF_EAPROG_SEC("cgroup/sendmsg4", BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+ BPF_CGROUP_UDP4_SENDMSG),
+ BPF_EAPROG_SEC("cgroup/sendmsg6", BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
+ BPF_CGROUP_UDP6_SENDMSG),
};
+#undef BPF_PROG_SEC_IMPL
#undef BPF_PROG_SEC
-#undef BPF_PROG_SEC_FULL
-#undef BPF_S_PROG_SEC
-#undef BPF_SA_PROG_SEC
+#undef BPF_APROG_SEC
+#undef BPF_EAPROG_SEC
+#undef BPF_APROG_COMPAT
int libbpf_prog_type_by_name(const char *name, enum bpf_prog_type *prog_type,
enum bpf_attach_type *expected_attach_type)
@@ -2156,6 +2180,25 @@ int libbpf_prog_type_by_name(const char *name, enum bpf_prog_type *prog_type,
return -EINVAL;
}
+int libbpf_attach_type_by_name(const char *name,
+ enum bpf_attach_type *attach_type)
+{
+ int i;
+
+ if (!name)
+ return -EINVAL;
+
+ for (i = 0; i < ARRAY_SIZE(section_names); i++) {
+ if (strncmp(name, section_names[i].sec, section_names[i].len))
+ continue;
+ if (section_names[i].attach_type == -EINVAL)
+ return -EINVAL;
+ *attach_type = section_names[i].attach_type;
+ return 0;
+ }
+ return -EINVAL;
+}
+
static int
bpf_program__identify_section(struct bpf_program *prog,
enum bpf_prog_type *prog_type,
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index e3b00e23e181..511c1294dcbf 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -104,6 +104,8 @@ void *bpf_object__priv(struct bpf_object *prog);
int libbpf_prog_type_by_name(const char *name, enum bpf_prog_type *prog_type,
enum bpf_attach_type *expected_attach_type);
+int libbpf_attach_type_by_name(const char *name,
+ enum bpf_attach_type *attach_type);
/* Accessors of bpf_program */
struct bpf_program;
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 3/5] libbpf: Support sk_skb/stream_{parser,verdict} section names
From: Andrey Ignatov @ 2018-09-26 22:24 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team
In-Reply-To: <cover.1538000102.git.rdna@fb.com>
Add section names for BPF_SK_SKB_STREAM_PARSER and
BPF_SK_SKB_STREAM_VERDICT attach types to be able to identify them in
libbpf_attach_type_by_name.
"stream_parser" and "stream_verdict" are used instead of simple "parser"
and "verdict" just to avoid possible confusion in a place where attach
type is used alone (e.g. in bpftool's show sub-commands) since there is
another attach point that can be named as "verdict": BPF_SK_MSG_VERDICT.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/lib/bpf/libbpf.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 51edf6cd390e..425d5ca45c97 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -2139,6 +2139,10 @@ static const struct {
BPF_CGROUP_DEVICE),
BPF_APROG_SEC("sockops", BPF_PROG_TYPE_SOCK_OPS,
BPF_CGROUP_SOCK_OPS),
+ BPF_APROG_SEC("sk_skb/stream_parser", BPF_PROG_TYPE_SK_SKB,
+ BPF_SK_SKB_STREAM_PARSER),
+ BPF_APROG_SEC("sk_skb/stream_verdict", BPF_PROG_TYPE_SK_SKB,
+ BPF_SK_SKB_STREAM_VERDICT),
BPF_APROG_COMPAT("sk_skb", BPF_PROG_TYPE_SK_SKB),
BPF_APROG_SEC("sk_msg", BPF_PROG_TYPE_SK_MSG,
BPF_SK_MSG_VERDICT),
--
2.17.1
^ permalink raw reply related
* [PATCH bpf-next 0/5] Introduce libbpf_attach_type_by_name
From: Andrey Ignatov @ 2018-09-26 22:24 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team
This patch set introduces libbpf_attach_type_by_name function in libbpf to
identify attach type by section name.
This is useful to avoid writing same logic over and over again in user
space applications that leverage libbpf.
Patch 1 has more details on the new function and problem being solved.
Patches 2 and 3 add support for new section names.
Patch 4 uses new function in a selftest.
Patch 5 adds selftest for libbpf_{prog,attach}_type_by_name.
As a side note there are a lot of inconsistencies now between names used by
libbpf and bpftool (e.g. cgroup/skb vs cgroup_skb, cgroup_device and device
vs cgroup/dev, sockops vs sock_ops, etc). This patch set does not address
it but it tries not to make it harder to address it in the future.
Andrey Ignatov (5):
libbpf: Introduce libbpf_attach_type_by_name
libbpf: Support cgroup_skb/{e,in}gress section names
libbpf: Support sk_skb/stream_{parser,verdict} section names
selftests/bpf: Use libbpf_attach_type_by_name in test_socket_cookie
selftests/bpf: Test libbpf_{prog,attach}_type_by_name
tools/lib/bpf/libbpf.c | 129 +++++++----
tools/lib/bpf/libbpf.h | 2 +
tools/testing/selftests/bpf/Makefile | 2 +-
.../selftests/bpf/test_section_names.c | 208 ++++++++++++++++++
.../selftests/bpf/test_socket_cookie.c | 6 +-
5 files changed, 302 insertions(+), 45 deletions(-)
create mode 100644 tools/testing/selftests/bpf/test_section_names.c
--
2.17.1
^ permalink raw reply
* [PATCH bpf-next 2/5] libbpf: Support cgroup_skb/{e,in}gress section names
From: Andrey Ignatov @ 2018-09-26 22:24 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kernel-team
In-Reply-To: <cover.1538000102.git.rdna@fb.com>
Add section names for BPF_CGROUP_INET_INGRESS and BPF_CGROUP_INET_EGRESS
attach types to be able to identify them in libbpf_attach_type_by_name.
"cgroup_skb" is used instead of "cgroup/skb" mostly to easy possible
unifying of how libbpf and bpftool works with section names:
* bpftool uses "cgroup_skb" to in "prog list" sub-command;
* bpftool uses "ingress" and "egress" in "cgroup list" sub-command;
* having two parts instead of three in a string like "cgroup_skb/ingress"
can be leveraged to split it to prog_type part and attach_type part,
or vise versa: use two parts to make a section name.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
tools/lib/bpf/libbpf.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 59e589a64d5c..51edf6cd390e 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -2124,6 +2124,10 @@ static const struct {
BPF_PROG_SEC("lwt_out", BPF_PROG_TYPE_LWT_OUT),
BPF_PROG_SEC("lwt_xmit", BPF_PROG_TYPE_LWT_XMIT),
BPF_PROG_SEC("lwt_seg6local", BPF_PROG_TYPE_LWT_SEG6LOCAL),
+ BPF_APROG_SEC("cgroup_skb/ingress", BPF_PROG_TYPE_CGROUP_SKB,
+ BPF_CGROUP_INET_INGRESS),
+ BPF_APROG_SEC("cgroup_skb/egress", BPF_PROG_TYPE_CGROUP_SKB,
+ BPF_CGROUP_INET_EGRESS),
BPF_APROG_COMPAT("cgroup/skb", BPF_PROG_TYPE_CGROUP_SKB),
BPF_APROG_SEC("cgroup/sock", BPF_PROG_TYPE_CGROUP_SOCK,
BPF_CGROUP_INET_SOCK_CREATE),
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v2] wireless-drivers: rtnetlink wifi simulation device
From: Kalle Valo @ 2018-09-27 4:34 UTC (permalink / raw)
To: Cody Schuffelen
Cc: Johannes Berg, David S . Miller, linux-kernel, linux-wireless,
netdev, kernel-team
In-Reply-To: <20180926194324.71290-1-schuffelen@google.com>
Cody Schuffelen <schuffelen@google.com> writes:
> This device takes over an existing network device and produces a
> new one that appears like a wireless connection, returning enough canned
> responses to nl80211 to satisfy a standard network manager. If
> necessary, it can also be set up one step removed from an existing
> network device, such as through a vlan/80211Q or macvlan connection to
> not disrupt the existing network interface.
>
> To use it to wrap a bare ethernet connection:
>
> ip link set eth0 down
> ip link set eth0 name buried_eth0
> ip link set buried_eth0 up
> ip link add link buried_eth0 name wlan0 type virt_wifi
>
> eth0 is renamed to buried_eth0 to avoid a network manager trying to
> manage it, as the original network link will become unusuable and only
> the wireless wrapper will be functional. This can also be combined with
> vlan or macvlan links on top of eth0 to share the network between
> distinct links, but that requires support outside the machine for
> accepting vlan-tagged packets or packets from multiple MAC addresses.
>
> This is being used for Google's Remote Android Virtual Device project,
> which runs Android devices in virtual machines. The standard network
> interfaces provided inside the virtual machines are all ethernet.
> However, Android is not interested in ethernet devices and would rather
> connect to a wireless interface. This patch allows the virtual machine
> guest to treat one of its network connections as wireless rather than
> ethernet, satisfying Android's network connection requirements.
>
> We believe this is a generally useful driver for simulating wireless
> network connections in other environments where a wireless connection is
> desired by some userspace process but is not available. Future work can
> also include exporting the wireless control plane to userspace, so the
> device can configure the behavior of the simulated wireless network
> itself.
>
> This is distinct from other testing efforts such as mac80211_hwsim by
> being a cfg80211 device instead of mac80211 device, allowing straight
> pass-through on the data plane instead of forcing packaging of ethernet
> data into mac80211 frames.
>
> Signed-off-by: A. Cody Schuffelen <schuffelen@google.com>
> Acked-by: Alistair Strachan <astrachan@google.com>
> Acked-by: Greg Hartman <ghartman@google.com>
> Signed-off-by: Cody Schuffelen <schuffelen@google.com>
[...]
> --- a/drivers/net/wireless/Kconfig
> +++ b/drivers/net/wireless/Kconfig
> @@ -114,4 +114,11 @@ config USB_NET_RNDIS_WLAN
>
> If you choose to build a module, it'll be called rndis_wlan.
>
> +config VIRT_WIFI
> + tristate "Wifi wrapper for ethernet drivers"
> + default n
Isn't 'n' the default so you don't need to explicitly set that?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net-next v2] wireless-drivers: rtnetlink wifi simulation device
From: Kalle Valo @ 2018-09-27 4:33 UTC (permalink / raw)
To: Cody Schuffelen
Cc: Johannes Berg, David S . Miller, linux-kernel, linux-wireless,
netdev, kernel-team
In-Reply-To: <20180926194324.71290-1-schuffelen@google.com>
Cody Schuffelen <schuffelen@google.com> writes:
> This device takes over an existing network device and produces a
> new one that appears like a wireless connection, returning enough canned
> responses to nl80211 to satisfy a standard network manager. If
> necessary, it can also be set up one step removed from an existing
> network device, such as through a vlan/80211Q or macvlan connection to
> not disrupt the existing network interface.
>
> To use it to wrap a bare ethernet connection:
>
> ip link set eth0 down
> ip link set eth0 name buried_eth0
> ip link set buried_eth0 up
> ip link add link buried_eth0 name wlan0 type virt_wifi
>
> eth0 is renamed to buried_eth0 to avoid a network manager trying to
> manage it, as the original network link will become unusuable and only
> the wireless wrapper will be functional. This can also be combined with
> vlan or macvlan links on top of eth0 to share the network between
> distinct links, but that requires support outside the machine for
> accepting vlan-tagged packets or packets from multiple MAC addresses.
>
> This is being used for Google's Remote Android Virtual Device project,
> which runs Android devices in virtual machines. The standard network
> interfaces provided inside the virtual machines are all ethernet.
> However, Android is not interested in ethernet devices and would rather
> connect to a wireless interface. This patch allows the virtual machine
> guest to treat one of its network connections as wireless rather than
> ethernet, satisfying Android's network connection requirements.
>
> We believe this is a generally useful driver for simulating wireless
> network connections in other environments where a wireless connection is
> desired by some userspace process but is not available. Future work can
> also include exporting the wireless control plane to userspace, so the
> device can configure the behavior of the simulated wireless network
> itself.
>
> This is distinct from other testing efforts such as mac80211_hwsim by
> being a cfg80211 device instead of mac80211 device, allowing straight
> pass-through on the data plane instead of forcing packaging of ethernet
> data into mac80211 frames.
>
> Signed-off-by: A. Cody Schuffelen <schuffelen@google.com>
> Acked-by: Alistair Strachan <astrachan@google.com>
> Acked-by: Greg Hartman <ghartman@google.com>
> Signed-off-by: Cody Schuffelen <schuffelen@google.com>
> ---
> Original change: https://lore.kernel.org/lkml/5b5b8e09.1c69fb81.c693c.0acd@mx.google.com/
> First review: https://lore.kernel.org/lkml/1535460343.5895.56.camel@sipsolutions.net/
>
> Thanks for the detailed review! I believe I've addressed all comments.
BTW, this will likely go through mac80211-next, so don't add net-next to
the subject to avoid Dave getting confused. But no need to resend
because of this.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC PATCH v2 bpf-next 0/2] verifier liveness simplification
From: Jiong Wang @ 2018-09-26 22:16 UTC (permalink / raw)
To: Edward Cree, ast, daniel; +Cc: netdev
In-Reply-To: <d16ea072-61a0-8f8a-aca1-13cac09d3d14@solarflare.com>
On 22/08/2018 20:00, Edward Cree wrote:
> The first patch is a simplification of register liveness tracking by using
> a separate parentage chain for each register and stack slot, thus avoiding
> the need for logic to handle callee-saved registers when applying read
> marks. In the future this idea may be extended to form use-def chains.
Interesting.
This could potentially help efficient code-gen for 32-bit architectures and I
had been thinking some implementations along this line and would like to have
a discussion.
Program description
===
It will be good if we could know one instruction is safe to operate on low
32-bit sub-register only. If this is true:
- 32-bit arches could save some code-gen.
- 64-bit arches could utilize 32-bit sub-register instructions.
Algorithm
===
Based on the current verifier code-path-walker, it looks to me we could get
32-bit safety information using the following algorithm:
1. assume all instructions operate on 32-bit sub-register initially.
2. link each insn to insns which define its use.
3. for a register use, if it is a 64-bit write back to memory, or if it is
a comparison-then-jump based on 64-bit value, or if it is a right shift,
then consider the use is a 64-bit use, then all its define insns and their
parents define insns should be marked as need full 64-bit operation.
4. currently, register read (REG_LIVE_READ) will be propagated to parent
state when path prune happened, and REG_LIVE_WRITTEN would screen off such
propagation. We need to propagate 64-bit mark in similar way, but
REG_LIVE_WRITTEN shouldn't screen off backward 64-bit mark propagation if
the written reg also used as source reg (this has raised REG_LIVE_READ
propagation but it is not necessarily indicating 64-bit read) in the same
instruction.
Implementation
===
And it seems there could be an implementation based on current liveness tracking
infrastructure without dramatic change.
1. instruction level use->def chain
- new active_defs array for each call frame to record which insn the active
define of one register comes from. callee copies active_defs from caller
for argument registers only, and copies active_def of R0 to caller when
exit.
struct bpf_func_state {
...
s16 active_defs[__MAX_BPF_REG];
- new use->def chains for each instruction. one eBPF insn could have two
uses at maximum. also one new boolean "full_ref_def" added to keep the
final 32-bit safety information. it will be true if this instruction
needs to operate on full 64-bit.
bpf_insn_aux_data {
...
struct {
s16 def[2];
bool full_ref_def;
};
2. Inside mark_reg_read, split SRC_OP to SRC0_OP/SRC1_OP/SRC_OP_64/SRC1_OP_64
to indicate one register read if from the first or second use slot of this
instruction, and to indicate whether the read is on full 64-bit which will
only be true if the read is for 64-bit write back to memory, or 64-bit
comparison-then-jump, or bit right shift means 64-bit.
Build use->def chain for any read, but do 64-bit backward propagation
for 64-bit read only. The propagation is to set full_ref_def to true for
def and parent defs of the 64-bit read.
3. Need new bpf_reg_liveness enum, REG_LIVE_READ64 to indicate there is
64-bit access to one register in the pruned path, and need
REG_LIVE_WRITTEN64 to indicate a write that is REG_LIVE_WRITTEN but should
not screen backward propagate 64-bit read info.
#define REG_LIVE_NONE 0
#define REG_LIVE_READ BIT(0)
#define REG_LIVE_READ64 BIT(1)
#define REG_LIVE_WRITTEN BIT(2)
#define REG_LIVE_WRITTEN64 BIT(3)
I might have missed something in above thoughts, would appreciate reviews and
suggestions. I will also send out some concrete patches later.
Regards,
Jiong
^ permalink raw reply
* Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
From: Andrew Lunn @ 2018-09-26 21:58 UTC (permalink / raw)
To: Neil Horman
Cc: Chris Preimesberger, linville@tuxdriver.com,
netdev@vger.kernel.org
In-Reply-To: <20180926213436.GA4116@hmswarspite.think-freely.org>
> When you run ethtool -m on this driver, the kernel calls mlx4_en_get_module_info
> to determine the length of the eeprom, and that value will be either 256 or 512
> bytes.
So it sounds like QSFP modules using 8636 are not supported. You would
expect a size to be one of 256, 384, 512 or 640.
> Next it calls mlx4_en_get_module_eeprom, passing in that size 256 to actually
> read the eeprom data, which in turn calls mlx4_get_module_info to fetch the data
> from hardware, again, passing in 256 as the size for the first call (theres a
> loop, but it will only get executed once in this scenario)
>
> mlx4_get_module_info then issues the appropriate mailbox commands to dump the
> eeprom. Here it starts to go sideways. The mailbox buffer allocated for the
> return data is of type mlx4_mad_ifc, which has some front matter information and
> a data buffer that is 192 bytes long!
Which suggests all SFP dumps are broken as well, not just QSFP.
Oh dear.
Andrew
^ permalink raw reply
* [PATCH net] r8169: Enable MSI-X on RTL8106e
From: Jian-Hong Pan @ 2018-09-27 4:09 UTC (permalink / raw)
To: David S . Miller, Heiner Kallweit
Cc: Realtek linux nic maintainers, netdev, linux-kernel,
kai.heng.feng, linux, Jian-Hong Pan
Originally, we have an issue where r8169 MSI-X interrupt is broken after
S3 suspend/resume on RTL8106e of ASUS X441UAR.
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller [10ec:8136]
(rev 07)
Subsystem: ASUSTeK Computer Inc. RTL810xE PCI Express Fast
Ethernet controller [1043:200f]
Flags: bus master, fast devsel, latency 0, IRQ 16
I/O ports at e000 [size=256]
Memory at ef100000 (64-bit, non-prefetchable) [size=4K]
Memory at e0000000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-36-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Kernel driver in use: r8169
Kernel modules: r8169
We found the all of the values in PCI BAR=4 of the ethernet adapter
become 0xFF after system resumes. That breaks the MSI-X interrupt.
Therefore, we can only fall back to MSI interrupt to fix the issue at
that time.
However, there is a commit which resolves the drivers getting nothing in
PCI BAR=4 after system resumes. It is 04cb3ae895d7 "PCI: Reprogram
bridge prefetch registers on resume" by Daniel Drake.
After apply the patch, the ethernet adapter works fine before suspend
and after resume. So, we can revert the workaround after the commit
"PCI: Reprogram bridge prefetch registers on resume" is merged into main
tree.
This patch reverts commit 7bb05b85bc2d1a1b647b91424b2ed4a18e6ecd81
"r8169: don't use MSI-X on RTL8106e".
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=201181
Fixes: 7bb05b85bc2d ("r8169: don't use MSI-X on RTL8106e")
Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
---
drivers/net/ethernet/realtek/r8169.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index bb529ff2ca81..445508c7e067 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -7084,20 +7084,17 @@ static int rtl_alloc_irq(struct rtl8169_private *tp)
{
unsigned int flags;
- switch (tp->mac_version) {
- case RTL_GIGA_MAC_VER_01 ... RTL_GIGA_MAC_VER_06:
+ if (tp->mac_version <= RTL_GIGA_MAC_VER_06) {
RTL_W8(tp, Cfg9346, Cfg9346_Unlock);
RTL_W8(tp, Config2, RTL_R8(tp, Config2) & ~MSIEnable);
RTL_W8(tp, Cfg9346, Cfg9346_Lock);
flags = PCI_IRQ_LEGACY;
- break;
- case RTL_GIGA_MAC_VER_39 ... RTL_GIGA_MAC_VER_40:
+ } else if (tp->mac_version == RTL_GIGA_MAC_VER_40) {
/* This version was reported to have issues with resume
* from suspend when using MSI-X
*/
flags = PCI_IRQ_LEGACY | PCI_IRQ_MSI;
- break;
- default:
+ } else {
flags = PCI_IRQ_ALL_TYPES;
}
--
2.11.0
^ permalink raw reply related
* Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
From: Andrew Lunn @ 2018-09-26 21:46 UTC (permalink / raw)
To: Chris Preimesberger; +Cc: linville@tuxdriver.com, netdev@vger.kernel.org
In-Reply-To: <82CEAF9FFBA4DD428B132074FB91DF7D5F64838C@CSI-MAILSRV.csicompanies.internal>
On Wed, Sep 26, 2018 at 08:47:34PM +0000, Chris Preimesberger wrote:
> Hello Andrew,
>
> Thank you for the quick response!!
> Apologies in advance for my use of outlook and top-posting, etc...
>
> I've run the raw option and the hex option, and pasted the results below.
> Since the raw option printed strange characters on the CLI, I re-ran it,
> Sending the output to a file (raw.txt) and attached that file as well.
>
> Pasted from Ubuntu CLI:
>
> tech1@D7:~$
> tech1@D7:~$
> tech1@D7:~$
> tech1@D7:~$
> tech1@D7:~$ sudo ethtool -m enp1s0 raw on
> \x11UU$��pA`?�@�G\x10#
> �\x12v\x01\x11��\x03�\x02@TRANSITION ��TNQSFP100GCWDM4 1AfX%\x1cF?\x06?�TN02000301 180919
> h�\x02I��_��'\x16��Ri=\x02`��Zntech1@D7:~$
> tech1@D7:~$
> tech1@D7:~$
> tech1@D7:~$
> tech1@D7:~$ sudo ethtool -m enp1s0 hex on
> Offset Values
> ------ ------
> 0x0000: 11 00 00 0f 00 00 00 00 00 55 55 00 00 00 00 00
> 0x0010: 00 00 00 00 00 00 24 e2 00 00 81 68 00 00 00 00
> 0x0020: 00 00 00 00 00 00 00 00 00 00 41 60 3f e0 40 e0
> 0x0030: 47 00 1f 10 0e 1e 0b f7 12 76 00 00 00 00 00 00
> 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
> 0x0060: 00 00 00 00 00 00 00 00 00 00 1f 00 00 00 00 00
> 0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 0x0080: 11 fc 07 80 00 00 00 00 00 00 00 03 ff 00 02 00
> 0x0090: 00 00 00 40 54 52 41 4e 53 49 54 49 4f 4e 20 20
> 0x00a0: 20 20 20 20 00 00 c0 f2 54 4e 51 53 46 50 31 30
> 0x00b0: 30 47 43 57 44 4d 34 20 31 41 66 58 25 1c 46 3f
> 0x00c0: 06 00 3f d6 54 4e 30 32 30 30 30 33 30 31 20 20
> 0x00d0: 20 20 20 20 31 38 30 39 31 39 20 20 0c 00 68 f3
> 0x00e0: 00 00 02 49 80 a0 5f 1f de c9 27 16 f8 ae 52 69
> 0x00f0: 3d 02 60 00 00 00 00 00 00 00 00 00 83 f4 5a 6e
Hi Chris
I've only recently got involved with SFP modules. ethtool says this is
a SFF-8636 SFP. So a QSFP. It has multiple pages, each 128 bytes in
length, which should be returned in a concatenated form. Here we see
256 bytes, meaning there are two pages. There can be up to 5 pages.
ethtool is looking for the temperature alarms at offset 0x200. So that
does not exist in this hex dump. But the raw dump you provided has
more bytes, 0x400 of them.
So i would say the first bug is that ethtool dumps different amounts
of data in hex than raw.
The fact you get different alarm thresholds on different runs suggests
to me we might only be getting two pages from the kernel?
Can you build ethtool from source and run it inside a debugger?
ethtool makes two IOCTL calls. The first is ETHTOOL_GMODULEINFO.
Could you print out the modinfo which is returned. It then does a
ETHTOOL_GMODULEEEPROM. Can you print out eeprom after the second
IOCTL.
Thanks
Andrew
^ permalink raw reply
* Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
From: Neil Horman @ 2018-09-26 21:34 UTC (permalink / raw)
To: Chris Preimesberger; +Cc: linville@tuxdriver.com, netdev@vger.kernel.org
In-Reply-To: <82CEAF9FFBA4DD428B132074FB91DF7D5F6481EA@CSI-MAILSRV.csicompanies.internal>
On Wed, Sep 26, 2018 at 07:29:23PM +0000, Chris Preimesberger wrote:
> Hello,
>
> I'm re-sending in plain text per the auto-reply from a spam filter. I have attached some text files this time, which explain the situation below, in case the below email's font & formatting is now too messed up for easy comprehension.
>
> Thank you and best regards.
>
>
> Chris Preimesberger | Test & Validation Engineer
> Transition Networks, Inc.
>
> chrisp@transition.com
> direct: +1.952.996.1509 | fax: +1.952.941.2322 | www.transition.com
> ________________________________________
>
>
>
This is just a drive by guess, but I think this is a driver issue.
Issue 1 seems like a red herring, cat doesn't modify output, nor does ethtool
know if its output is going to a console or a pipe, its all the same. And given
issue 2 (that the output of the thresholds, etc are spurriously changing and
wrong), suggests that they are spurriously changing and wrong regardless of what
cat does.
That said, I think issue two is a problem with the mlx4 driver. Specifically
that the driver is copying garbage data.
The three ethtool functions at work here are:
mlx4_en_get_module_info
mlx4_en_get_module_eeprom
mlx4_get_module_info
When you run ethtool -m on this driver, the kernel calls mlx4_en_get_module_info
to determine the length of the eeprom, and that value will be either 256 or 512
bytes. Lets assume that the value is 256 for the sake of argument
Next it calls mlx4_en_get_module_eeprom, passing in that size 256 to actually
read the eeprom data, which in turn calls mlx4_get_module_info to fetch the data
from hardware, again, passing in 256 as the size for the first call (theres a
loop, but it will only get executed once in this scenario)
mlx4_get_module_info then issues the appropriate mailbox commands to dump the
eeprom. Here it starts to go sideways. The mailbox buffer allocated for the
return data is of type mlx4_mad_ifc, which has some front matter information and
a data buffer that is 192 bytes long!
A little further down in the function, size gets restricted if the buffer
crosses a page boundary, but given that the size is 256 on the first call here,
and offset is zero on the first call, we're not crossing anything, so size
remains unchanged.
The output mailbox buffer outmad->data (a 192 byte array), then gets cast to a
sturt mlx4_cable_info structure, which has its own internal data buffer that is
only 48 bytes long.
The memcpy in this functionthen copies cable_info->data to the buffer that gets
returned to ethtool, but it copies size bytes (256), even though the source data
buffer is only 48 bytes long. That 48 byte array is embedded in the larger 192
byte structure, so there won't be a panic on the overrun, but theres no telling
what garbage is in the buffer beyond those first 48 bytes. Even if the
remaining 144 bytes have valid eeprom data, its less than the required 256
bytes. The additional copy may cause a panic, but if the buffer commonly bumps
up against other allocated memory, that will go unnoticed.
after the memcpy, mlx4_get_module_info just returns the size of the passed in
buffer (256), and so the calling function thinks its work is done, and lets the
kernel send back the buffer with garbage data to ethtool.
I think the mlx4 guys have some work to do here.
My $0.02
Neil
>
>
> From: Chris Preimesberger
> Sent: Wednesday, September 26, 2018 2:14 PM
> To: 'linville@tuxdriver.com'; 'netdev@vger.kernel.org'
> Subject: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers
>
> Hello John, All,
>
>
> I think I may have found a bug or two in ethtool, with respect to its reporting of a QSFP28 transceiver's diagnostic information. Ethtool seems to correctly report all diagnostic information about QSFP28 transceivers, except for the transceiver's warning and alarm thresholds. I'm not sure whether the spurious warning and alarm values that get reported are the fault of ethtool or my NIC/driver, and I have no other models of 100GbE NICs to test with. I've contacted Mellanox support about this, and they point the finger at ethtool. Can these issues be investigated by ethtool developers? Here is some background information about the equipment and software used when I observe these issues:
>
> Equipment used:
> NIC: Mellanox ConnectX-4 100GbE, part number MCX415A-CCAT
> Transceiver: Any 40Gb or 100Gb QSFP28 transceiver installed in the NIC (Intel, Mellanox, Transition Networks, etc..)
>
> Software used:
> Ubuntu 18.04 with the distro's packaged NIC driver and ethtool v4.15
> also tested were ethtool v4.18 compiled from source and the current Mellanox OFED driver.
>
> All test scenarios produced the same bugs.
>
>
> Bug #1. Ethtool's reporting of the installed transceiver's alarm and warning thresholds will differ, depending on whether or not ethtool is piped to another command. Example commands are below, with their respective differing output values highlighted:
>
>
> tech1@D8:~$ sudo ethtool -m enp1s0
> Identifier : 0x11 (QSFP28)
> Extended identifier : 0xfc
> Extended identifier description : 3.5W max. Power consumption
> Extended identifier description : CDR present in TX, CDR present in RX
> Extended identifier description : High Power Class (> 3.5 W) not enabled
> Connector : 0x07 (LC)
> Transceiver codes : 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Transceiver type : 100G Ethernet: 100G CWDM4 MSA with FEC
> Encoding : 0x03 (NRZ)
> BR, Nominal : 25500Mbps
> Rate identifier : 0x00
> Length (SMF,km) : 2km
> Length (OM3 50um) : 0m
> Length (OM2 50um) : 0m
> Length (OM1 62.5um) : 0m
> Length (Copper or Active cable) : 0m
> Transmitter technology : 0x40 (1310 nm DFB)
> Laser wavelength : 1310.000nm
> Laser wavelength tolerance : 47.500nm
> Vendor name : TRANSITION
> Vendor OUI : 00:c0:f2
> Vendor PN : TNQSFP100GCWDM4
> Vendor rev : 1A
> Vendor SN : TN02000302
> Date code : 180919
> Revision Compliance : SFF-8636 Rev 2.5/2.6/2.7
> Module temperature : 39.53 degrees C / 103.15 degrees F
> Module voltage : 3.3241 V
> Alarm/warning flags implemented : Yes
> Laser tx bias current (Channel 1) : 34.432 mA
> Laser tx bias current (Channel 2) : 34.432 mA
> Laser tx bias current (Channel 3) : 33.408 mA
> Laser tx bias current (Channel 4) : 33.920 mA
> Transmit avg optical power (Channel 1) : 0.9048 mW / -0.43 dBm
> Transmit avg optical power (Channel 2) : 0.7832 mW / -1.06 dBm
> Transmit avg optical power (Channel 3) : 0.8057 mW / -0.94 dBm
> Transmit avg optical power (Channel 4) : 0.7014 mW / -1.54 dBm
> Rcvr signal avg optical power(Channel 1) : 0.7378 mW / -1.32 dBm
> Rcvr signal avg optical power(Channel 2) : 0.7553 mW / -1.22 dBm
> Rcvr signal avg optical power(Channel 3) : 0.6529 mW / -1.85 dBm
> Rcvr signal avg optical power(Channel 4) : 0.6847 mW / -1.64 dBm
> Laser bias current high alarm (Chan 1) : Off
> Laser bias current low alarm (Chan 1) : Off
> Laser bias current high warning (Chan 1) : Off
> Laser bias current low warning (Chan 1) : Off
> Laser bias current high alarm (Chan 2) : Off
> Laser bias current low alarm (Chan 2) : Off
> Laser bias current high warning (Chan 2) : Off
> Laser bias current low warning (Chan 2) : Off
> Laser bias current high alarm (Chan 3) : Off
> Laser bias current low alarm (Chan 3) : Off
> Laser bias current high warning (Chan 3) : Off
> Laser bias current low warning (Chan 3) : Off
> Laser bias current high alarm (Chan 4) : Off
> Laser bias current low alarm (Chan 4) : Off
> Laser bias current high warning (Chan 4) : Off
> Laser bias current low warning (Chan 4) : Off
> Module temperature high alarm : Off
> Module temperature low alarm : Off
> Module temperature high warning : Off
> Module temperature low warning : Off
> Module voltage high alarm : Off
> Module voltage low alarm : Off
> Module voltage high warning : Off
> Module voltage low warning : Off
> Laser tx power high alarm (Channel 1) : Off
> Laser tx power low alarm (Channel 1) : Off
> Laser tx power high warning (Channel 1) : Off
> Laser tx power low warning (Channel 1) : Off
> Laser tx power high alarm (Channel 2) : Off
> Laser tx power low alarm (Channel 2) : Off
> Laser tx power high warning (Channel 2) : Off
> Laser tx power low warning (Channel 2) : Off
> Laser tx power high alarm (Channel 3) : Off
> Laser tx power low alarm (Channel 3) : Off
> Laser tx power high warning (Channel 3) : Off
> Laser tx power low warning (Channel 3) : Off
> Laser tx power high alarm (Channel 4) : Off
> Laser tx power low alarm (Channel 4) : Off
> Laser tx power high warning (Channel 4) : Off
> Laser tx power low warning (Channel 4) : Off
> Laser rx power high alarm (Channel 1) : Off
> Laser rx power low alarm (Channel 1) : Off
> Laser rx power high warning (Channel 1) : Off
> Laser rx power low warning (Channel 1) : Off
> Laser rx power high alarm (Channel 2) : Off
> Laser rx power low alarm (Channel 2) : Off
> Laser rx power high warning (Channel 2) : Off
> Laser rx power low warning (Channel 2) : Off
> Laser rx power high alarm (Channel 3) : Off
> Laser rx power low alarm (Channel 3) : Off
> Laser rx power high warning (Channel 3) : Off
> Laser rx power low warning (Channel 3) : Off
> Laser rx power high alarm (Channel 4) : Off
> Laser rx power low alarm (Channel 4) : Off
> Laser rx power high warning (Channel 4) : Off
> Laser rx power low warning (Channel 4) : Off
> Laser bias current high alarm threshold : 0.000 mA
> Laser bias current low alarm threshold : 0.000 mA
> Laser bias current high warning threshold : 0.000 mA
> Laser bias current low warning threshold : 0.000 mA
> Laser output power high alarm threshold : 0.0000 mW / -inf dBm
> Laser output power low alarm threshold : 0.0000 mW / -inf dBm
> Laser output power high warning threshold : 0.0000 mW / -inf dBm
> Laser output power low warning threshold : 0.0000 mW / -inf dBm
> Module temperature high alarm threshold : 0.00 degrees C / 32.00 degrees F
> Module temperature low alarm threshold : 0.00 degrees C / 32.00 degrees F
> Module temperature high warning threshold : 0.00 degrees C / 32.00 degrees F
> Module temperature low warning threshold : 0.00 degrees C / 32.00 degrees F
> Module voltage high alarm threshold : 0.0000 V
> Module voltage low alarm threshold : 0.0000 V
> Module voltage high warning threshold : 0.0000 V
> Module voltage low warning threshold : 0.0000 V
> Laser rx power high alarm threshold : 0.0000 mW / -inf dBm
> Laser rx power low alarm threshold : 0.0000 mW / -inf dBm
> Laser rx power high warning threshold : 0.0000 mW / -inf dBm
> Laser rx power low warning threshold : 0.0000 mW / -inf dBm
>
>
> tech1@D8:~$ sudo ethtool -m enp1s0 | cat
> Identifier : 0x11 (QSFP28)
> Extended identifier : 0xfc
> Extended identifier description : 3.5W max. Power consumption
> Extended identifier description : CDR present in TX, CDR present in RX
> Extended identifier description : High Power Class (> 3.5 W) not enabled
> Connector : 0x07 (LC)
> Transceiver codes : 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Transceiver type : 100G Ethernet: 100G CWDM4 MSA with FEC
> Encoding : 0x03 (NRZ)
> BR, Nominal : 25500Mbps
> Rate identifier : 0x00
> Length (SMF,km) : 2km
> Length (OM3 50um) : 0m
> Length (OM2 50um) : 0m
> Length (OM1 62.5um) : 0m
> Length (Copper or Active cable) : 0m
> Transmitter technology : 0x40 (1310 nm DFB)
> Laser wavelength : 1310.000nm
> Laser wavelength tolerance : 47.500nm
> Vendor name : TRANSITION
> Vendor OUI : 00:c0:f2
> Vendor PN : TNQSFP100GCWDM4
> Vendor rev : 1A
> Vendor SN : TN02000302
> Date code : 180919
> Revision Compliance : SFF-8636 Rev 2.5/2.6/2.7
> Module temperature : 39.53 degrees C / 103.15 degrees F
> Module voltage : 3.3249 V
> Alarm/warning flags implemented : Yes
> Laser tx bias current (Channel 1) : 34.432 mA
> Laser tx bias current (Channel 2) : 34.432 mA
> Laser tx bias current (Channel 3) : 33.408 mA
> Laser tx bias current (Channel 4) : 33.920 mA
> Transmit avg optical power (Channel 1) : 0.9043 mW / -0.44 dBm
> Transmit avg optical power (Channel 2) : 0.7832 mW / -1.06 dBm
> Transmit avg optical power (Channel 3) : 0.8057 mW / -0.94 dBm
> Transmit avg optical power (Channel 4) : 0.7009 mW / -1.54 dBm
> Rcvr signal avg optical power(Channel 1) : 0.7378 mW / -1.32 dBm
> Rcvr signal avg optical power(Channel 2) : 0.7553 mW / -1.22 dBm
> Rcvr signal avg optical power(Channel 3) : 0.6529 mW / -1.85 dBm
> Rcvr signal avg optical power(Channel 4) : 0.6847 mW / -1.64 dBm
> Laser bias current high alarm (Chan 1) : Off
> Laser bias current low alarm (Chan 1) : Off
> Laser bias current high warning (Chan 1) : Off
> Laser bias current low warning (Chan 1) : Off
> Laser bias current high alarm (Chan 2) : Off
> Laser bias current low alarm (Chan 2) : Off
> Laser bias current high warning (Chan 2) : Off
> Laser bias current low warning (Chan 2) : Off
> Laser bias current high alarm (Chan 3) : Off
> Laser bias current low alarm (Chan 3) : Off
> Laser bias current high warning (Chan 3) : Off
> Laser bias current low warning (Chan 3) : Off
> Laser bias current high alarm (Chan 4) : Off
> Laser bias current low alarm (Chan 4) : Off
> Laser bias current high warning (Chan 4) : Off
> Laser bias current low warning (Chan 4) : Off
> Module temperature high alarm : Off
> Module temperature low alarm : Off
> Module temperature high warning : Off
> Module temperature low warning : Off
> Module voltage high alarm : Off
> Module voltage low alarm : Off
> Module voltage high warning : Off
> Module voltage low warning : Off
> Laser tx power high alarm (Channel 1) : Off
> Laser tx power low alarm (Channel 1) : Off
> Laser tx power high warning (Channel 1) : Off
> Laser tx power low warning (Channel 1) : Off
> Laser tx power high alarm (Channel 2) : Off
> Laser tx power low alarm (Channel 2) : Off
> Laser tx power high warning (Channel 2) : Off
> Laser tx power low warning (Channel 2) : Off
> Laser tx power high alarm (Channel 3) : Off
> Laser tx power low alarm (Channel 3) : Off
> Laser tx power high warning (Channel 3) : Off
> Laser tx power low warning (Channel 3) : Off
> Laser tx power high alarm (Channel 4) : Off
> Laser tx power low alarm (Channel 4) : Off
> Laser tx power high warning (Channel 4) : Off
> Laser tx power low warning (Channel 4) : Off
> Laser rx power high alarm (Channel 1) : Off
> Laser rx power low alarm (Channel 1) : Off
> Laser rx power high warning (Channel 1) : Off
> Laser rx power low warning (Channel 1) : Off
> Laser rx power high alarm (Channel 2) : Off
> Laser rx power low alarm (Channel 2) : Off
> Laser rx power high warning (Channel 2) : Off
> Laser rx power low warning (Channel 2) : Off
> Laser rx power high alarm (Channel 3) : Off
> Laser rx power low alarm (Channel 3) : Off
> Laser rx power high warning (Channel 3) : Off
> Laser rx power low warning (Channel 3) : Off
> Laser rx power high alarm (Channel 4) : Off
> Laser rx power low alarm (Channel 4) : Off
> Laser rx power high warning (Channel 4) : Off
> Laser rx power low warning (Channel 4) : Off
> Laser bias current high alarm threshold : 16.448 mA
> Laser bias current low alarm threshold : 16.448 mA
> Laser bias current high warning threshold : 16.448 mA
> Laser bias current low warning threshold : 16.448 mA
> Laser output power high alarm threshold : 0.8224 mW / -0.85 dBm
> Laser output power low alarm threshold : 0.8250 mW / -0.84 dBm
> Laser output power high warning threshold : 0.8264 mW / -0.83 dBm
> Laser output power low warning threshold : 2.6983 mW / 4.31 dBm
> Module temperature high alarm threshold : 110.12 degrees C / 230.22 degrees F
> Module temperature low alarm threshold : 84.34 degrees C / 183.82 degrees F
> Module temperature high warning threshold : 44.12 degrees C / 111.42 degrees F
> Module temperature low warning threshold : 67.27 degrees C / 153.08 degrees F
> Module voltage high alarm threshold : 2.9728 V
> Module voltage low alarm threshold : 2.6990 V
> Module voltage high warning threshold : 0.8274 V
> Module voltage low warning threshold : 2.2538 V
> Laser rx power high alarm threshold : 2.5458 mW / 4.06 dBm
> Laser rx power low alarm threshold : 2.6992 mW / 4.31 dBm
> Laser rx power high warning threshold : 2.9801 mW / 4.74 dBm
> Laser rx power low warning threshold : 2.8526 mW / 4.55 dBm
>
>
> Bug # 2. All of the alarm and warning threshold values reported in the above commands are spurious.
> At first glance, one would assume that the threshold values reported by the piped ethtool command are correct, but they're not. I know the programmed values for the above transceiver, so that makes it easy for me to spot the spurious values, but even without knowing the programmed values of a given transceiver, one can use logic to detect when the ethtool displayed values don't make sense.
> For example, lets scrutinize the values for voltage warnings and alarms reported by ethtool on this transceiver. We will look at each voltage threshold, and scrutinize that value relative to the other voltage thresholds, and look for contradictions to determine whether the reported values seem legit.
> Known ethtool
> Actual Reported
> Values Values
> High Voltage Alarm 3.70V 2.9728 V
> High Voltage Warning 3.59V 0.8274 V
> (Operating spec = 3.30V)
> Low Voltage Warning 3.00V 2.2538 V
> Low Voltage Alarm 2.90V 2.6990 V
>
> Contradictions for the ethtool reported voltage warning and alarm thresholds:
> 1. The high voltage alarm should occur at higher voltage than the operating voltage, but ethtool didn't report that.
> 2. The high voltage warning should occur at higher voltage than the low voltage warning and alarm, but ethtool didn't report that.
> 3. The low voltage warning should occur at higher voltage than the low voltage alarm, but ethtool didn't report that.
> 4. The low voltage alarm should occur at a lower voltage than any of the other voltage warnings and alarms, but ethtool didn't report that.
> 5. The current voltage value was reported as 3.3249V, which should trigger high voltage warning and alarm, according to the reported thresholds, but no warnings or alarms are indicated.
>
> Each of the 4 voltage thresholds reported by ethtool have contradictions, so we know something is not right. This same kind of logic can be applied to the thresholds for temperature, laser TX power, etc.. to find that those values are also spurious.
>
>
> Installing the above transceiver in a Cisco switch reveals that the Cisco correctly retrieves the true warning and alarm threshold values from the transceiver's EEPROM, so we trust that the transceiver has been correctly programmed. Cisco CLI output for that transceiver shown here:
>
> switch# show interface ethernet 1/3 transceiver details
> Ethernet1/3
> transceiver is present
> type is QSFP-100G-CWDM4-MSA-FEC
> name is TRANSITION
> part number is TNQSFP100GCWDM4
> revision is 1A
> serial number is TN02000302
> nominal bitrate is 25500 MBit/sec per channel
> Link length supported for 9/125um fiber is 2 km
> cisco id is 17
> cisco extended id number is 252
>
> Lane Number:1 Network Lane
> SFP Detail Diagnostics Information (internal calibration)
> ----------------------------------------------------------------------------
> Current Alarms Warnings
> Measurement High Low High Low
> ----------------------------------------------------------------------------
> Temperature 38.08 C 80.00 C -10.00 C 75.00 C -5.00 C
> Voltage 3.34 V 3.70 V 2.90 V 3.59 V 3.00 V
> Current 34.24 mA 75.00 mA 10.00 mA 70.00 mA 15.00 mA
> Tx Power -0.44 dBm 4.49 dBm -8.50 dBm 3.49 dBm -7.52 dBm
> Rx Power N/A 4.49 dBm -14.55 dBm 3.49 dBm -12.51 dBm
> Transmit Fault Count = 0
> ----------------------------------------------------------------------------
> Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning
>
> Lane Number:2 Network Lane
> SFP Detail Diagnostics Information (internal calibration)
> ----------------------------------------------------------------------------
> Current Alarms Warnings
> Measurement High Low High Low
> ----------------------------------------------------------------------------
> Temperature 38.08 C 80.00 C -10.00 C 75.00 C -5.00 C
> Voltage 3.34 V 3.70 V 2.90 V 3.59 V 3.00 V
> Current 34.24 mA 75.00 mA 10.00 mA 70.00 mA 15.00 mA
> Tx Power -1.20 dBm 4.49 dBm -8.50 dBm 3.49 dBm -7.52 dBm
> Rx Power N/A 4.49 dBm -14.55 dBm 3.49 dBm -12.51 dBm
> Transmit Fault Count = 0
> ----------------------------------------------------------------------------
> Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning
>
> Lane Number:3 Network Lane
> SFP Detail Diagnostics Information (internal calibration)
> ----------------------------------------------------------------------------
> Current Alarms Warnings
> Measurement High Low High Low
> ----------------------------------------------------------------------------
> Temperature 38.08 C 80.00 C -10.00 C 75.00 C -5.00 C
> Voltage 3.34 V 3.70 V 2.90 V 3.59 V 3.00 V
> Current 33.21 mA 75.00 mA 10.00 mA 70.00 mA 15.00 mA
> Tx Power -0.96 dBm 4.49 dBm -8.50 dBm 3.49 dBm -7.52 dBm
> Rx Power N/A 4.49 dBm -14.55 dBm 3.49 dBm -12.51 dBm
> Transmit Fault Count = 0
> ----------------------------------------------------------------------------
> Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning
>
> Lane Number:4 Network Lane
> SFP Detail Diagnostics Information (internal calibration)
> ----------------------------------------------------------------------------
> Current Alarms Warnings
> Measurement High Low High Low
> ----------------------------------------------------------------------------
> Temperature 38.08 C 80.00 C -10.00 C 75.00 C -5.00 C
> Voltage 3.34 V 3.70 V 2.90 V 3.59 V 3.00 V
> Current 33.72 mA 75.00 mA 10.00 mA 70.00 mA 15.00 mA
> Tx Power -1.59 dBm 4.49 dBm -8.50 dBm 3.49 dBm -7.52 dBm
> Rx Power N/A 4.49 dBm -14.55 dBm 3.49 dBm -12.51 dBm
> Transmit Fault Count = 0
> ----------------------------------------------------------------------------
> Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning
>
> switch#
>
>
> Any help with these issues is greatly appreciated. If you have any questions or advice, please let me know. I'll be glad to continue troubleshooting this until it's resolved. Thank you.
>
>
> Chris Preimesberger | Test & Validation Engineer
> Transition Networks, Inc.
>
> chrisp@transition.com
> direct: +1.952.996.1509 | fax: +1.952.941.2322 | www.transition.com
> ________________________________________
>
>
>
>
>
>
>
> For comparison to ethtool's output that shows incorrect threshold values, when installing the same transceiver in a Cisco Nexus switch, and issuing the Cisco command "show interface ethernet 1/3 transceiver details", the switch correctly correctly reads/displays the transceiver's Alarm and Warning thresholds, as shown below:
>
>
> switch# show interface ethernet 1/3 transceiver details
> Ethernet1/3
> transceiver is present
> type is QSFP-100G-CWDM4-MSA-FEC
> name is TRANSITION
> part number is TNQSFP100GCWDM4
> revision is 1A
> serial number is TN02000302
> nominal bitrate is 25500 MBit/sec per channel
> Link length supported for 9/125um fiber is 2 km
> cisco id is 17
> cisco extended id number is 252
>
> Lane Number:1 Network Lane
> SFP Detail Diagnostics Information (internal calibration)
> ----------------------------------------------------------------------------
> Current Alarms Warnings
> Measurement High Low High Low
> ----------------------------------------------------------------------------
> Temperature 38.08 C 80.00 C -10.00 C 75.00 C -5.00 C
> Voltage 3.34 V 3.70 V 2.90 V 3.59 V 3.00 V
> Current 34.24 mA 75.00 mA 10.00 mA 70.00 mA 15.00 mA
> Tx Power -0.44 dBm 4.49 dBm -8.50 dBm 3.49 dBm -7.52 dBm
> Rx Power N/A 4.49 dBm -14.55 dBm 3.49 dBm -12.51 dBm
> Transmit Fault Count = 0
> ----------------------------------------------------------------------------
> Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning
>
> Lane Number:2 Network Lane
> SFP Detail Diagnostics Information (internal calibration)
> ----------------------------------------------------------------------------
> Current Alarms Warnings
> Measurement High Low High Low
> ----------------------------------------------------------------------------
> Temperature 38.08 C 80.00 C -10.00 C 75.00 C -5.00 C
> Voltage 3.34 V 3.70 V 2.90 V 3.59 V 3.00 V
> Current 34.24 mA 75.00 mA 10.00 mA 70.00 mA 15.00 mA
> Tx Power -1.20 dBm 4.49 dBm -8.50 dBm 3.49 dBm -7.52 dBm
> Rx Power N/A 4.49 dBm -14.55 dBm 3.49 dBm -12.51 dBm
> Transmit Fault Count = 0
> ----------------------------------------------------------------------------
> Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning
>
> Lane Number:3 Network Lane
> SFP Detail Diagnostics Information (internal calibration)
> ----------------------------------------------------------------------------
> Current Alarms Warnings
> Measurement High Low High Low
> ----------------------------------------------------------------------------
> Temperature 38.08 C 80.00 C -10.00 C 75.00 C -5.00 C
> Voltage 3.34 V 3.70 V 2.90 V 3.59 V 3.00 V
> Current 33.21 mA 75.00 mA 10.00 mA 70.00 mA 15.00 mA
> Tx Power -0.96 dBm 4.49 dBm -8.50 dBm 3.49 dBm -7.52 dBm
> Rx Power N/A 4.49 dBm -14.55 dBm 3.49 dBm -12.51 dBm
> Transmit Fault Count = 0
> ----------------------------------------------------------------------------
> Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning
>
> Lane Number:4 Network Lane
> SFP Detail Diagnostics Information (internal calibration)
> ----------------------------------------------------------------------------
> Current Alarms Warnings
> Measurement High Low High Low
> ----------------------------------------------------------------------------
> Temperature 38.08 C 80.00 C -10.00 C 75.00 C -5.00 C
> Voltage 3.34 V 3.70 V 2.90 V 3.59 V 3.00 V
> Current 33.72 mA 75.00 mA 10.00 mA 70.00 mA 15.00 mA
> Tx Power -1.59 dBm 4.49 dBm -8.50 dBm 3.49 dBm -7.52 dBm
> Rx Power N/A 4.49 dBm -14.55 dBm 3.49 dBm -12.51 dBm
> Transmit Fault Count = 0
> ----------------------------------------------------------------------------
> Note: ++ high-alarm; + high-warning; -- low-alarm; - low-warning
>
> switch#
>
>
> Look at each line in the ethtool output below that includes the word "threshold". This file has been hand-edited to show the threshold values that have been programmed into the transceiver, which should be displayed by ethtool. The threshold values shown below are copied and pasted from the output of the Cisco NX-OS command "show interface ethernet 1/3 transceiver details", while the transceiver was installed in a Cisco Nexus switch.
>
> Note - I only copied the threshold values in the units that were displayed by the Cisco switch. The "?" symbols are just a placeholder for the converted values; I was too lazy to do conversions between dBm and mW, or between degrees C and degrees F. Ethtool would be expected to report the true / converted values.
>
>
>
>
> tech1@D8:~$ sudo ethtool -m enp1s0
> Identifier : 0x11 (QSFP28)
> Extended identifier : 0xfc
> Extended identifier description : 3.5W max. Power consumption
> Extended identifier description : CDR present in TX, CDR present in RX
> Extended identifier description : High Power Class (> 3.5 W) not enabled
> Connector : 0x07 (LC)
> Transceiver codes : 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Transceiver type : 100G Ethernet: 100G CWDM4 MSA with FEC
> Encoding : 0x03 (NRZ)
> BR, Nominal : 25500Mbps
> Rate identifier : 0x00
> Length (SMF,km) : 2km
> Length (OM3 50um) : 0m
> Length (OM2 50um) : 0m
> Length (OM1 62.5um) : 0m
> Length (Copper or Active cable) : 0m
> Transmitter technology : 0x40 (1310 nm DFB)
> Laser wavelength : 1310.000nm
> Laser wavelength tolerance : 47.500nm
> Vendor name : TRANSITION
> Vendor OUI : 00:c0:f2
> Vendor PN : TNQSFP100GCWDM4
> Vendor rev : 1A
> Vendor SN : TN02000302
> Date code : 180919
> Revision Compliance : SFF-8636 Rev 2.5/2.6/2.7
> Module temperature : 39.53 degrees C / 103.15 degrees F
> Module voltage : 3.3233 V
> Alarm/warning flags implemented : Yes
> Laser tx bias current (Channel 1) : 34.432 mA
> Laser tx bias current (Channel 2) : 34.432 mA
> Laser tx bias current (Channel 3) : 33.408 mA
> Laser tx bias current (Channel 4) : 33.920 mA
> Transmit avg optical power (Channel 1) : 0.9052 mW / -0.43 dBm
> Transmit avg optical power (Channel 2) : 0.7832 mW / -1.06 dBm
> Transmit avg optical power (Channel 3) : 0.8057 mW / -0.94 dBm
> Transmit avg optical power (Channel 4) : 0.7009 mW / -1.54 dBm
> Rcvr signal avg optical power(Channel 1) : 0.7378 mW / -1.32 dBm
> Rcvr signal avg optical power(Channel 2) : 0.7553 mW / -1.22 dBm
> Rcvr signal avg optical power(Channel 3) : 0.6529 mW / -1.85 dBm
> Rcvr signal avg optical power(Channel 4) : 0.6948 mW / -1.58 dBm
> Laser bias current high alarm (Chan 1) : Off
> Laser bias current low alarm (Chan 1) : Off
> Laser bias current high warning (Chan 1) : Off
> Laser bias current low warning (Chan 1) : Off
> Laser bias current high alarm (Chan 2) : Off
> Laser bias current low alarm (Chan 2) : Off
> Laser bias current high warning (Chan 2) : Off
> Laser bias current low warning (Chan 2) : Off
> Laser bias current high alarm (Chan 3) : Off
> Laser bias current low alarm (Chan 3) : Off
> Laser bias current high warning (Chan 3) : Off
> Laser bias current low warning (Chan 3) : Off
> Laser bias current high alarm (Chan 4) : Off
> Laser bias current low alarm (Chan 4) : Off
> Laser bias current high warning (Chan 4) : Off
> Laser bias current low warning (Chan 4) : Off
> Module temperature high alarm : Off
> Module temperature low alarm : Off
> Module temperature high warning : Off
> Module temperature low warning : Off
> Module voltage high alarm : Off
> Module voltage low alarm : Off
> Module voltage high warning : Off
> Module voltage low warning : Off
> Laser tx power high alarm (Channel 1) : Off
> Laser tx power low alarm (Channel 1) : Off
> Laser tx power high warning (Channel 1) : Off
> Laser tx power low warning (Channel 1) : Off
> Laser tx power high alarm (Channel 2) : Off
> Laser tx power low alarm (Channel 2) : Off
> Laser tx power high warning (Channel 2) : Off
> Laser tx power low warning (Channel 2) : Off
> Laser tx power high alarm (Channel 3) : Off
> Laser tx power low alarm (Channel 3) : Off
> Laser tx power high warning (Channel 3) : Off
> Laser tx power low warning (Channel 3) : Off
> Laser tx power high alarm (Channel 4) : Off
> Laser tx power low alarm (Channel 4) : Off
> Laser tx power high warning (Channel 4) : Off
> Laser tx power low warning (Channel 4) : Off
> Laser rx power high alarm (Channel 1) : Off
> Laser rx power low alarm (Channel 1) : Off
> Laser rx power high warning (Channel 1) : Off
> Laser rx power low warning (Channel 1) : Off
> Laser rx power high alarm (Channel 2) : Off
> Laser rx power low alarm (Channel 2) : Off
> Laser rx power high warning (Channel 2) : Off
> Laser rx power low warning (Channel 2) : Off
> Laser rx power high alarm (Channel 3) : Off
> Laser rx power low alarm (Channel 3) : Off
> Laser rx power high warning (Channel 3) : Off
> Laser rx power low warning (Channel 3) : Off
> Laser rx power high alarm (Channel 4) : Off
> Laser rx power low alarm (Channel 4) : Off
> Laser rx power high warning (Channel 4) : Off
> Laser rx power low warning (Channel 4) : Off
> Laser bias current high alarm threshold : 75.000 mA
> Laser bias current low alarm threshold : 10.000 mA
> Laser bias current high warning threshold : 70.000 mA
> Laser bias current low warning threshold : 15.000 mA
> Laser output power high alarm threshold : ? mW / 4.49 dBm
> Laser output power low alarm threshold : ? mW / -8.50 dBm
> Laser output power high warning threshold : ? mW / 3.49 dBm
> Laser output power low warning threshold : ? mW / -7.52 dBm
> Module temperature high alarm threshold : 80.00 degrees C / ? degrees F
> Module temperature low alarm threshold : -10.00 degrees C / ? degrees F
> Module temperature high warning threshold : 75.00 degrees C / ? degrees F
> Module temperature low warning threshold : -5.00 degrees C / ? degrees F
> Module voltage high alarm threshold : 3.7000 V
> Module voltage low alarm threshold : 2.9000 V
> Module voltage high warning threshold : 3.5900 V
> Module voltage low warning threshold : 3.0000 V
> Laser rx power high alarm threshold : ? mW / 4.49 dBm
> Laser rx power low alarm threshold : ? mW / -14.55 dBm
> Laser rx power high warning threshold : ? mW / 3.49 dBm
> Laser rx power low warning threshold : ? mW / -12.51 dBm
>
>
> Look at each line in the ethtool output below that includes the word "threshold". This file shows the actual output from ethtool v4.18, when the output is not piped to another command. Notice that all of the displayed threshold values are 0 (which is incorrect), while other values report as expected.
>
> tech1@D8:~$ sudo ethtool -m enp1s0
> Identifier : 0x11 (QSFP28)
> Extended identifier : 0xfc
> Extended identifier description : 3.5W max. Power consumption
> Extended identifier description : CDR present in TX, CDR present in RX
> Extended identifier description : High Power Class (> 3.5 W) not enabled
> Connector : 0x07 (LC)
> Transceiver codes : 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Transceiver type : 100G Ethernet: 100G CWDM4 MSA with FEC
> Encoding : 0x03 (NRZ)
> BR, Nominal : 25500Mbps
> Rate identifier : 0x00
> Length (SMF,km) : 2km
> Length (OM3 50um) : 0m
> Length (OM2 50um) : 0m
> Length (OM1 62.5um) : 0m
> Length (Copper or Active cable) : 0m
> Transmitter technology : 0x40 (1310 nm DFB)
> Laser wavelength : 1310.000nm
> Laser wavelength tolerance : 47.500nm
> Vendor name : TRANSITION
> Vendor OUI : 00:c0:f2
> Vendor PN : TNQSFP100GCWDM4
> Vendor rev : 1A
> Vendor SN : TN02000302
> Date code : 180919
> Revision Compliance : SFF-8636 Rev 2.5/2.6/2.7
> Module temperature : 39.53 degrees C / 103.15 degrees F
> Module voltage : 3.3241 V
> Alarm/warning flags implemented : Yes
> Laser tx bias current (Channel 1) : 34.432 mA
> Laser tx bias current (Channel 2) : 34.432 mA
> Laser tx bias current (Channel 3) : 33.408 mA
> Laser tx bias current (Channel 4) : 33.920 mA
> Transmit avg optical power (Channel 1) : 0.9048 mW / -0.43 dBm
> Transmit avg optical power (Channel 2) : 0.7832 mW / -1.06 dBm
> Transmit avg optical power (Channel 3) : 0.8057 mW / -0.94 dBm
> Transmit avg optical power (Channel 4) : 0.7014 mW / -1.54 dBm
> Rcvr signal avg optical power(Channel 1) : 0.7378 mW / -1.32 dBm
> Rcvr signal avg optical power(Channel 2) : 0.7553 mW / -1.22 dBm
> Rcvr signal avg optical power(Channel 3) : 0.6529 mW / -1.85 dBm
> Rcvr signal avg optical power(Channel 4) : 0.6847 mW / -1.64 dBm
> Laser bias current high alarm (Chan 1) : Off
> Laser bias current low alarm (Chan 1) : Off
> Laser bias current high warning (Chan 1) : Off
> Laser bias current low warning (Chan 1) : Off
> Laser bias current high alarm (Chan 2) : Off
> Laser bias current low alarm (Chan 2) : Off
> Laser bias current high warning (Chan 2) : Off
> Laser bias current low warning (Chan 2) : Off
> Laser bias current high alarm (Chan 3) : Off
> Laser bias current low alarm (Chan 3) : Off
> Laser bias current high warning (Chan 3) : Off
> Laser bias current low warning (Chan 3) : Off
> Laser bias current high alarm (Chan 4) : Off
> Laser bias current low alarm (Chan 4) : Off
> Laser bias current high warning (Chan 4) : Off
> Laser bias current low warning (Chan 4) : Off
> Module temperature high alarm : Off
> Module temperature low alarm : Off
> Module temperature high warning : Off
> Module temperature low warning : Off
> Module voltage high alarm : Off
> Module voltage low alarm : Off
> Module voltage high warning : Off
> Module voltage low warning : Off
> Laser tx power high alarm (Channel 1) : Off
> Laser tx power low alarm (Channel 1) : Off
> Laser tx power high warning (Channel 1) : Off
> Laser tx power low warning (Channel 1) : Off
> Laser tx power high alarm (Channel 2) : Off
> Laser tx power low alarm (Channel 2) : Off
> Laser tx power high warning (Channel 2) : Off
> Laser tx power low warning (Channel 2) : Off
> Laser tx power high alarm (Channel 3) : Off
> Laser tx power low alarm (Channel 3) : Off
> Laser tx power high warning (Channel 3) : Off
> Laser tx power low warning (Channel 3) : Off
> Laser tx power high alarm (Channel 4) : Off
> Laser tx power low alarm (Channel 4) : Off
> Laser tx power high warning (Channel 4) : Off
> Laser tx power low warning (Channel 4) : Off
> Laser rx power high alarm (Channel 1) : Off
> Laser rx power low alarm (Channel 1) : Off
> Laser rx power high warning (Channel 1) : Off
> Laser rx power low warning (Channel 1) : Off
> Laser rx power high alarm (Channel 2) : Off
> Laser rx power low alarm (Channel 2) : Off
> Laser rx power high warning (Channel 2) : Off
> Laser rx power low warning (Channel 2) : Off
> Laser rx power high alarm (Channel 3) : Off
> Laser rx power low alarm (Channel 3) : Off
> Laser rx power high warning (Channel 3) : Off
> Laser rx power low warning (Channel 3) : Off
> Laser rx power high alarm (Channel 4) : Off
> Laser rx power low alarm (Channel 4) : Off
> Laser rx power high warning (Channel 4) : Off
> Laser rx power low warning (Channel 4) : Off
> Laser bias current high alarm threshold : 0.000 mA
> Laser bias current low alarm threshold : 0.000 mA
> Laser bias current high warning threshold : 0.000 mA
> Laser bias current low warning threshold : 0.000 mA
> Laser output power high alarm threshold : 0.0000 mW / -inf dBm
> Laser output power low alarm threshold : 0.0000 mW / -inf dBm
> Laser output power high warning threshold : 0.0000 mW / -inf dBm
> Laser output power low warning threshold : 0.0000 mW / -inf dBm
> Module temperature high alarm threshold : 0.00 degrees C / 32.00 degrees F
> Module temperature low alarm threshold : 0.00 degrees C / 32.00 degrees F
> Module temperature high warning threshold : 0.00 degrees C / 32.00 degrees F
> Module temperature low warning threshold : 0.00 degrees C / 32.00 degrees F
> Module voltage high alarm threshold : 0.0000 V
> Module voltage low alarm threshold : 0.0000 V
> Module voltage high warning threshold : 0.0000 V
> Module voltage low warning threshold : 0.0000 V
> Laser rx power high alarm threshold : 0.0000 mW / -inf dBm
> Laser rx power low alarm threshold : 0.0000 mW / -inf dBm
> Laser rx power high warning threshold : 0.0000 mW / -inf dBm
> Laser rx power low warning threshold : 0.0000 mW / -inf dBm
>
>
>
> Look at each line in the ethtool output below that includes the word "threshold". This file shows the actual output from ethtool v4.18, when the ethtool output is piped to another command. Notice that all of the displayed threshold values are spurious while other values report as expected.
>
> tech1@D8:~$ sudo ethtool -m enp1s0 | cat
> Identifier : 0x11 (QSFP28)
> Extended identifier : 0xfc
> Extended identifier description : 3.5W max. Power consumption
> Extended identifier description : CDR present in TX, CDR present in RX
> Extended identifier description : High Power Class (> 3.5 W) not enabled
> Connector : 0x07 (LC)
> Transceiver codes : 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> Transceiver type : 100G Ethernet: 100G CWDM4 MSA with FEC
> Encoding : 0x03 (NRZ)
> BR, Nominal : 25500Mbps
> Rate identifier : 0x00
> Length (SMF,km) : 2km
> Length (OM3 50um) : 0m
> Length (OM2 50um) : 0m
> Length (OM1 62.5um) : 0m
> Length (Copper or Active cable) : 0m
> Transmitter technology : 0x40 (1310 nm DFB)
> Laser wavelength : 1310.000nm
> Laser wavelength tolerance : 47.500nm
> Vendor name : TRANSITION
> Vendor OUI : 00:c0:f2
> Vendor PN : TNQSFP100GCWDM4
> Vendor rev : 1A
> Vendor SN : TN02000302
> Date code : 180919
> Revision Compliance : SFF-8636 Rev 2.5/2.6/2.7
> Module temperature : 39.53 degrees C / 103.15 degrees F
> Module voltage : 3.3249 V
> Alarm/warning flags implemented : Yes
> Laser tx bias current (Channel 1) : 34.432 mA
> Laser tx bias current (Channel 2) : 34.432 mA
> Laser tx bias current (Channel 3) : 33.408 mA
> Laser tx bias current (Channel 4) : 33.920 mA
> Transmit avg optical power (Channel 1) : 0.9043 mW / -0.44 dBm
> Transmit avg optical power (Channel 2) : 0.7832 mW / -1.06 dBm
> Transmit avg optical power (Channel 3) : 0.8057 mW / -0.94 dBm
> Transmit avg optical power (Channel 4) : 0.7009 mW / -1.54 dBm
> Rcvr signal avg optical power(Channel 1) : 0.7378 mW / -1.32 dBm
> Rcvr signal avg optical power(Channel 2) : 0.7553 mW / -1.22 dBm
> Rcvr signal avg optical power(Channel 3) : 0.6529 mW / -1.85 dBm
> Rcvr signal avg optical power(Channel 4) : 0.6847 mW / -1.64 dBm
> Laser bias current high alarm (Chan 1) : Off
> Laser bias current low alarm (Chan 1) : Off
> Laser bias current high warning (Chan 1) : Off
> Laser bias current low warning (Chan 1) : Off
> Laser bias current high alarm (Chan 2) : Off
> Laser bias current low alarm (Chan 2) : Off
> Laser bias current high warning (Chan 2) : Off
> Laser bias current low warning (Chan 2) : Off
> Laser bias current high alarm (Chan 3) : Off
> Laser bias current low alarm (Chan 3) : Off
> Laser bias current high warning (Chan 3) : Off
> Laser bias current low warning (Chan 3) : Off
> Laser bias current high alarm (Chan 4) : Off
> Laser bias current low alarm (Chan 4) : Off
> Laser bias current high warning (Chan 4) : Off
> Laser bias current low warning (Chan 4) : Off
> Module temperature high alarm : Off
> Module temperature low alarm : Off
> Module temperature high warning : Off
> Module temperature low warning : Off
> Module voltage high alarm : Off
> Module voltage low alarm : Off
> Module voltage high warning : Off
> Module voltage low warning : Off
> Laser tx power high alarm (Channel 1) : Off
> Laser tx power low alarm (Channel 1) : Off
> Laser tx power high warning (Channel 1) : Off
> Laser tx power low warning (Channel 1) : Off
> Laser tx power high alarm (Channel 2) : Off
> Laser tx power low alarm (Channel 2) : Off
> Laser tx power high warning (Channel 2) : Off
> Laser tx power low warning (Channel 2) : Off
> Laser tx power high alarm (Channel 3) : Off
> Laser tx power low alarm (Channel 3) : Off
> Laser tx power high warning (Channel 3) : Off
> Laser tx power low warning (Channel 3) : Off
> Laser tx power high alarm (Channel 4) : Off
> Laser tx power low alarm (Channel 4) : Off
> Laser tx power high warning (Channel 4) : Off
> Laser tx power low warning (Channel 4) : Off
> Laser rx power high alarm (Channel 1) : Off
> Laser rx power low alarm (Channel 1) : Off
> Laser rx power high warning (Channel 1) : Off
> Laser rx power low warning (Channel 1) : Off
> Laser rx power high alarm (Channel 2) : Off
> Laser rx power low alarm (Channel 2) : Off
> Laser rx power high warning (Channel 2) : Off
> Laser rx power low warning (Channel 2) : Off
> Laser rx power high alarm (Channel 3) : Off
> Laser rx power low alarm (Channel 3) : Off
> Laser rx power high warning (Channel 3) : Off
> Laser rx power low warning (Channel 3) : Off
> Laser rx power high alarm (Channel 4) : Off
> Laser rx power low alarm (Channel 4) : Off
> Laser rx power high warning (Channel 4) : Off
> Laser rx power low warning (Channel 4) : Off
> Laser bias current high alarm threshold : 16.448 mA
> Laser bias current low alarm threshold : 16.448 mA
> Laser bias current high warning threshold : 16.448 mA
> Laser bias current low warning threshold : 16.448 mA
> Laser output power high alarm threshold : 0.8224 mW / -0.85 dBm
> Laser output power low alarm threshold : 0.8250 mW / -0.84 dBm
> Laser output power high warning threshold : 0.8264 mW / -0.83 dBm
> Laser output power low warning threshold : 2.6983 mW / 4.31 dBm
> Module temperature high alarm threshold : 110.12 degrees C / 230.22 degrees F
> Module temperature low alarm threshold : 84.34 degrees C / 183.82 degrees F
> Module temperature high warning threshold : 44.12 degrees C / 111.42 degrees F
> Module temperature low warning threshold : 67.27 degrees C / 153.08 degrees F
> Module voltage high alarm threshold : 2.9728 V
> Module voltage low alarm threshold : 2.6990 V
> Module voltage high warning threshold : 0.8274 V
> Module voltage low warning threshold : 2.2538 V
> Laser rx power high alarm threshold : 2.5458 mW / 4.06 dBm
> Laser rx power low alarm threshold : 2.6992 mW / 4.31 dBm
> Laser rx power high warning threshold : 2.9801 mW / 4.74 dBm
> Laser rx power low warning threshold : 2.8526 mW / 4.55 dBm
> tech1@D8:~$
>
^ permalink raw reply
* Re: bpf: Massive skbuff_head_cache memory leak?
From: Daniel Borkmann @ 2018-09-26 21:22 UTC (permalink / raw)
To: Tetsuo Handa, Alexei Starovoitov
Cc: Network Development, David S. Miller, Dmitry Vyukov,
Andrew Morton, Michal Hocko, John Johansen
In-Reply-To: <c33e8c78-6112-7c0d-c816-98aab90575cc@I-love.SAKURA.ne.jp>
On 09/26/2018 11:09 PM, Tetsuo Handa wrote:
> Hello, Alexei and Daniel.
>
> Can you show us how to run testcases you are testing?
Sorry for the delay; currently quite backlogged but will definitely take a look
at these reports. Regarding your question: majority of test cases are in the
kernel tree under selftests, see tools/testing/selftests/bpf/ .
> On 2018/09/22 22:25, Tetsuo Handa wrote:
>> Hello.
>>
>> syzbot is reporting many lockup problems on bpf.git / bpf-next.git / net.git / net-next.git trees.
>>
>> INFO: rcu detected stall in br_multicast_port_group_expired (2)
>> https://syzkaller.appspot.com/bug?id=15c7ad8cf35a07059e8a697a22527e11d294bc94
>>
>> INFO: rcu detected stall in tun_chr_close
>> https://syzkaller.appspot.com/bug?id=6c50618bde03e5a2eefdd0269cf9739c5ebb8270
>>
>> INFO: rcu detected stall in discover_timer
>> https://syzkaller.appspot.com/bug?id=55da031ddb910e58ab9c6853a5784efd94f03b54
>>
>> INFO: rcu detected stall in ret_from_fork (2)
>> https://syzkaller.appspot.com/bug?id=c83129a6683b44b39f5b8864a1325893c9218363
>>
>> INFO: rcu detected stall in addrconf_rs_timer
>> https://syzkaller.appspot.com/bug?id=21c029af65f81488edbc07a10ed20792444711b6
>>
>> INFO: rcu detected stall in kthread (2)
>> https://syzkaller.appspot.com/bug?id=6accd1ed11c31110fed1982f6ad38cc9676477d2
>>
>> INFO: rcu detected stall in ext4_filemap_fault
>> https://syzkaller.appspot.com/bug?id=817e38d20e9ee53390ac361bf0fd2007eaf188af
>>
>> INFO: rcu detected stall in run_timer_softirq (2)
>> https://syzkaller.appspot.com/bug?id=f5a230a3ff7822f8d39fddf8485931bd06ae47fe
>>
>> INFO: rcu detected stall in bpf_prog_ADDR
>> https://syzkaller.appspot.com/bug?id=fb4911fd0e861171cc55124e209f810a0dd68744
>>
>> INFO: rcu detected stall in __run_timers (2)
>> https://syzkaller.appspot.com/bug?id=65416569ddc8d2feb8f19066aa761f5a47f7451a
>>
>> The cause of lockup seems to be flood of printk() messages from memory allocation
>> failures, and one of out_of_memory() messages indicates that skbuff_head_cache
>> usage is huge enough to suspect in-kernel memory leaks.
>>
>> [ 1554.547011] skbuff_head_cache 1847887KB 1847887KB
>>
>> Unfortunately, we cannot find from logs what syzbot is trying to do
>> because constant printk() messages is flooding away syzkaller messages.
>> Can you try running your testcases with kmemleak enabled?
>>
>
> On 2018/09/27 2:35, Dmitry Vyukov wrote:
>> I also started suspecting Apparmor. We switched to Apparmor on Aug 30:
>> https://groups.google.com/d/msg/syzkaller-bugs/o73lO4KGh0w/j9pcH2tSBAAJ
>> Now the instances that use SELinux and Smack explicitly contain that
>> in the name, but the rest are Apparmor.
>> Aug 30 roughly matches these assorted "task hung" reports. Perhaps
>> some Apparmor hook leaks a reference to skbs?
>
> Maybe. They have CONFIG_DEFAULT_SECURITY="apparmor". But I'm wondering why
> this problem is not occurring on linux-next.git when this problem is occurring
> on bpf.git / bpf-next.git / net.git / net-next.git trees. Is syzbot running
> different testcases depending on which git tree is targeted?
>
^ permalink raw reply
* Re: [PATCH] Documentation: Add HOWTO Korean translation into BPF and XDP Reference Guide.
From: Daniel Borkmann @ 2018-09-26 21:19 UTC (permalink / raw)
To: Jonathan Corbet, Chang-an Song; +Cc: tj, netdev, davem
In-Reply-To: <20180926134441.5e731b8b@lwn.net>
On 09/26/2018 09:44 PM, Jonathan Corbet wrote:
> On Wed, 26 Sep 2018 18:11:42 +0900
> Chang-an Song <csongxdp@gmail.com> wrote:
>
>>> - The original document has a copyright assertion but no associated
>>> license. Do we know what the license is? I assume it's something
>>> that is free and GPL-compatible, but that would be good to know for
>>> sure.
>>
>> 3. I asked to main author Daniel that apache 2.0 license for this document.
>
> That is a bit of a problem, since Apache v2 is not compatible with GPLv2.
> If the license of the document cannot be changed, I don't think we can
> accept it into the kernel tree.
Alternative option could also be to integrate it into Cilium's doc given the
original document is present there as well, so it could link to the Korean
version from there.
^ permalink raw reply
* Re: [PATCH net-next] net: mvneta: Add support for 2500Mbps SGMII
From: David Miller @ 2018-09-27 3:27 UTC (permalink / raw)
To: maxime.chevallier
Cc: netdev, linux-kernel, antoine.tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw, yelena,
linux-arm-kernel
In-Reply-To: <20180925135939.4816-1-maxime.chevallier@bootlin.com>
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date: Tue, 25 Sep 2018 15:59:39 +0200
> The mvneta controller can handle speeds up to 2500Mbps on the SGMII
> interface. This relies on serdes configuration, the lane must be
> configured at 3.125Gbps and we can't use in-band autoneg at that speed.
>
> The main issue when supporting that speed on this particular controller
> is that the link partner can send ethernet frames with a shortened
> preamble, which if not explicitly enabled in the controller will cause
> unexpected behaviours.
>
> This was tested on Armada 385, with the comphy configuration done in
> bootloader.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Applied.
^ permalink raw reply
* Re: bpf: Massive skbuff_head_cache memory leak?
From: Tetsuo Handa @ 2018-09-26 21:09 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: Network Development, David S. Miller, Dmitry Vyukov,
Andrew Morton, Michal Hocko, John Johansen
In-Reply-To: <b11ff285-1e8a-2729-d065-ac263572c511@I-love.SAKURA.ne.jp>
Hello, Alexei and Daniel.
Can you show us how to run testcases you are testing?
On 2018/09/22 22:25, Tetsuo Handa wrote:
> Hello.
>
> syzbot is reporting many lockup problems on bpf.git / bpf-next.git / net.git / net-next.git trees.
>
> INFO: rcu detected stall in br_multicast_port_group_expired (2)
> https://syzkaller.appspot.com/bug?id=15c7ad8cf35a07059e8a697a22527e11d294bc94
>
> INFO: rcu detected stall in tun_chr_close
> https://syzkaller.appspot.com/bug?id=6c50618bde03e5a2eefdd0269cf9739c5ebb8270
>
> INFO: rcu detected stall in discover_timer
> https://syzkaller.appspot.com/bug?id=55da031ddb910e58ab9c6853a5784efd94f03b54
>
> INFO: rcu detected stall in ret_from_fork (2)
> https://syzkaller.appspot.com/bug?id=c83129a6683b44b39f5b8864a1325893c9218363
>
> INFO: rcu detected stall in addrconf_rs_timer
> https://syzkaller.appspot.com/bug?id=21c029af65f81488edbc07a10ed20792444711b6
>
> INFO: rcu detected stall in kthread (2)
> https://syzkaller.appspot.com/bug?id=6accd1ed11c31110fed1982f6ad38cc9676477d2
>
> INFO: rcu detected stall in ext4_filemap_fault
> https://syzkaller.appspot.com/bug?id=817e38d20e9ee53390ac361bf0fd2007eaf188af
>
> INFO: rcu detected stall in run_timer_softirq (2)
> https://syzkaller.appspot.com/bug?id=f5a230a3ff7822f8d39fddf8485931bd06ae47fe
>
> INFO: rcu detected stall in bpf_prog_ADDR
> https://syzkaller.appspot.com/bug?id=fb4911fd0e861171cc55124e209f810a0dd68744
>
> INFO: rcu detected stall in __run_timers (2)
> https://syzkaller.appspot.com/bug?id=65416569ddc8d2feb8f19066aa761f5a47f7451a
>
> The cause of lockup seems to be flood of printk() messages from memory allocation
> failures, and one of out_of_memory() messages indicates that skbuff_head_cache
> usage is huge enough to suspect in-kernel memory leaks.
>
> [ 1554.547011] skbuff_head_cache 1847887KB 1847887KB
>
> Unfortunately, we cannot find from logs what syzbot is trying to do
> because constant printk() messages is flooding away syzkaller messages.
> Can you try running your testcases with kmemleak enabled?
>
On 2018/09/27 2:35, Dmitry Vyukov wrote:
> I also started suspecting Apparmor. We switched to Apparmor on Aug 30:
> https://groups.google.com/d/msg/syzkaller-bugs/o73lO4KGh0w/j9pcH2tSBAAJ
> Now the instances that use SELinux and Smack explicitly contain that
> in the name, but the rest are Apparmor.
> Aug 30 roughly matches these assorted "task hung" reports. Perhaps
> some Apparmor hook leaks a reference to skbs?
Maybe. They have CONFIG_DEFAULT_SECURITY="apparmor". But I'm wondering why
this problem is not occurring on linux-next.git when this problem is occurring
on bpf.git / bpf-next.git / net.git / net-next.git trees. Is syzbot running
different testcases depending on which git tree is targeted?
^ permalink raw reply
* Re: [PATCH] 9p: potential NULL dereference
From: Dominique Martinet @ 2018-09-26 21:07 UTC (permalink / raw)
To: Dan Carpenter
Cc: Eric Van Hensbergen, Matthew Wilcox, Latchesar Ionkov,
David S. Miller, v9fs-developer, netdev, kernel-janitors
In-Reply-To: <20180926103934.GA14535@mwanda>
Dan Carpenter wrote on Wed, Sep 26, 2018:
> p9_tag_alloc() is supposed to return error pointers, but we accidentally
> return a NULL here. It would cause a NULL dereference in the caller.
>
> Fixes: 996d5b4db4b1 ("9p: Use a slab for allocating requests")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Good catch, the culprit commit is only in -next so just adding this to
the queue right away.
Thanks!
--
Dominique
^ permalink raw reply
* Re: [PATCH v2] qed: Avoid implicit enum conversion in qed_roce_mode_to_flavor
From: David Miller @ 2018-09-27 3:19 UTC (permalink / raw)
To: natechancellor; +Cc: Ariel.Elior, everest-linux-l2, netdev, linux-kernel
In-Reply-To: <20180924213452.19334-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Mon, 24 Sep 2018 14:34:53 -0700
> Clang warns when one enumerated type is implicitly converted to another.
>
> drivers/net/ethernet/qlogic/qed/qed_roce.c:153:12: warning: implicit
> conversion from enumeration type 'enum roce_mode' to different
> enumeration type 'enum roce_flavor' [-Wenum-conversion]
> flavor = ROCE_V2_IPV6;
> ~ ^~~~~~~~~~~~
> drivers/net/ethernet/qlogic/qed/qed_roce.c:156:12: warning: implicit
> conversion from enumeration type 'enum roce_mode' to different
> enumeration type 'enum roce_flavor' [-Wenum-conversion]
> flavor = MAX_ROCE_MODE;
> ~ ^~~~~~~~~~~~~
> 2 warnings generated.
>
> Use the appropriate values from the expected type, roce_flavor:
>
> ROCE_V2_IPV6 = RROCE_IPV6 = 2
> MAX_ROCE_MODE = MAX_ROCE_FLAVOR = 3
>
> While we're add it, ditch the local variable flavor, we can just return
> the value directly from the switch statement.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/125
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
>
> v1 -> v2:
>
> * s/if statement/switch statement/ in commit message
Applied.
^ permalink raw reply
* Re: [PATCH] qed: Fix mask parameter in qed_vf_prep_tunn_req_tlv
From: David Miller @ 2018-09-27 3:19 UTC (permalink / raw)
To: natechancellor; +Cc: Ariel.Elior, everest-linux-l2, netdev, linux-kernel
In-Reply-To: <20180924210527.11996-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Mon, 24 Sep 2018 14:05:27 -0700
> Clang complains when one enumerated type is implicitly converted to
> another.
>
> drivers/net/ethernet/qlogic/qed/qed_vf.c:686:6: warning: implicit
> conversion from enumeration type 'enum qed_tunn_mode' to different
> enumeration type 'enum qed_tunn_clss' [-Wenum-conversion]
> QED_MODE_L2GENEVE_TUNN,
> ^~~~~~~~~~~~~~~~~~~~~~
>
> Update mask's parameter to expect qed_tunn_mode, which is what was
> intended.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/125
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Applied
^ permalink raw reply
* Re: [PATCH] qed: Avoid implicit enum conversion in qed_set_tunn_cls_info
From: David Miller @ 2018-09-27 3:16 UTC (permalink / raw)
To: natechancellor; +Cc: Ariel.Elior, everest-linux-l2, netdev, linux-kernel
In-Reply-To: <20180924205334.7337-1-natechancellor@gmail.com>
From: Nathan Chancellor <natechancellor@gmail.com>
Date: Mon, 24 Sep 2018 13:53:34 -0700
> Clang warns when one enumerated type is implicitly converted to another.
...
> Link: https://github.com/ClangBuiltLinux/linux/issues/125
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Applied.
^ permalink raw reply
* [RFC] netlink: add policy validation function for binary attributes
From: Johannes Berg @ 2018-09-26 20:57 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Add the ability to have an arbitrary validation function attached
to NLA_BINARY.
NOTE: obviously, the nl80211 part should be split off, that's just
to show how it might be used - saves ~1.2KiB there (x86-64)
NOTE: should probably allow this for the exact length fields, and
perhaps even provide a general NLA_POLICY_VALID_ETH_ADDR define
and similar?
---
include/net/netlink.h | 6 +++++
lib/nlattr.c | 6 +++++
net/wireless/nl80211.c | 67 ++++++++++++++------------------------------------
3 files changed, 31 insertions(+), 48 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index ddabc832febc..ff80ccbfc6b0 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -256,6 +256,10 @@ enum {
* of s16 - do that as usual in the code instead.
* All other Unused - but note that it's a union
*
+ * Meaning of `validate' field:
+ * NLA_BINARY Validation function called for the binary attribute
+ * All other Unused - but note that it's a union
+ *
* Example:
* static const struct nla_policy my_policy[ATTR_MAX+1] = {
* [ATTR_FOO] = { .type = NLA_U16 },
@@ -272,6 +276,8 @@ struct nla_policy {
struct {
s16 min, max;
};
+ int (*validate)(const struct nlattr *attr,
+ struct netlink_ext_ack *extack);
};
};
diff --git a/lib/nlattr.c b/lib/nlattr.c
index dd8d34c1ae19..4f003da28918 100644
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -175,6 +175,12 @@ static int validate_nla(const struct nlattr *nla, int maxtype,
case NLA_BINARY:
if (pt->len && attrlen > pt->len)
goto out_err;
+
+ if (pt->len && pt->validate) {
+ err = pt->validate(nla, extack);
+ if (err)
+ return err;
+ }
break;
case NLA_NESTED:
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 551310d5965e..a09066896f64 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -200,6 +200,9 @@ cfg80211_get_dev_from_info(struct net *netns, struct genl_info *info)
return __cfg80211_rdev_from_attrs(netns, info->attrs);
}
+static int validate_ie_attr(const struct nlattr *attr,
+ struct netlink_ext_ack *extack);
+
/* policy for the attributes */
static const struct nla_policy
nl80211_pmsr_ftm_req_attr_policy[NL80211_PMSR_FTM_REQ_ATTR_MAX + 1] = {
@@ -311,7 +314,8 @@ const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_BEACON_HEAD] = { .type = NLA_BINARY,
.len = IEEE80211_MAX_DATA_LEN },
[NL80211_ATTR_BEACON_TAIL] = { .type = NLA_BINARY,
- .len = IEEE80211_MAX_DATA_LEN },
+ .len = IEEE80211_MAX_DATA_LEN,
+ .validate = validate_ie_attr },
[NL80211_ATTR_STA_AID] = {
.type = NLA_U16,
.min = 1,
@@ -348,7 +352,8 @@ const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
[NL80211_ATTR_MGMT_SUBTYPE] = { .type = NLA_U8 },
[NL80211_ATTR_IE] = { .type = NLA_BINARY,
- .len = IEEE80211_MAX_DATA_LEN },
+ .len = IEEE80211_MAX_DATA_LEN,
+ .validate = validate_ie_attr },
[NL80211_ATTR_SCAN_FREQUENCIES] = { .type = NLA_NESTED },
[NL80211_ATTR_SCAN_SSIDS] = { .type = NLA_NESTED },
@@ -417,9 +422,11 @@ const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
.max = NL80211_HIDDEN_SSID_ZERO_CONTENTS,
},
[NL80211_ATTR_IE_PROBE_RESP] = { .type = NLA_BINARY,
- .len = IEEE80211_MAX_DATA_LEN },
+ .len = IEEE80211_MAX_DATA_LEN,
+ .validate = validate_ie_attr },
[NL80211_ATTR_IE_ASSOC_RESP] = { .type = NLA_BINARY,
- .len = IEEE80211_MAX_DATA_LEN },
+ .len = IEEE80211_MAX_DATA_LEN,
+ .validate = validate_ie_attr },
[NL80211_ATTR_ROAM_SUPPORT] = { .type = NLA_FLAG },
[NL80211_ATTR_SCHED_SCAN_MATCH] = { .type = NLA_NESTED },
[NL80211_ATTR_TX_NO_CCK_RATE] = { .type = NLA_FLAG },
@@ -738,14 +745,12 @@ static int nl80211_prepare_wdev_dump(struct sk_buff *skb,
}
/* IE validation */
-static bool is_valid_ie_attr(const struct nlattr *attr)
+static int validate_ie_attr(const struct nlattr *attr,
+ struct netlink_ext_ack *extack)
{
const u8 *pos;
int len;
- if (!attr)
- return true;
-
pos = nla_data(attr);
len = nla_len(attr);
@@ -753,18 +758,18 @@ static bool is_valid_ie_attr(const struct nlattr *attr)
u8 elemlen;
if (len < 2)
- return false;
+ return -EINVAL;
len -= 2;
elemlen = pos[1];
if (elemlen > len)
- return false;
+ return -EINVAL;
len -= elemlen;
pos += 2 + elemlen;
}
- return true;
+ return 0;
}
/* message building helper */
@@ -4191,12 +4196,6 @@ static int nl80211_parse_beacon(struct nlattr *attrs[],
{
bool haveinfo = false;
- if (!is_valid_ie_attr(attrs[NL80211_ATTR_BEACON_TAIL]) ||
- !is_valid_ie_attr(attrs[NL80211_ATTR_IE]) ||
- !is_valid_ie_attr(attrs[NL80211_ATTR_IE_PROBE_RESP]) ||
- !is_valid_ie_attr(attrs[NL80211_ATTR_IE_ASSOC_RESP]))
- return -EINVAL;
-
memset(bcn, 0, sizeof(*bcn));
if (attrs[NL80211_ATTR_BEACON_HEAD]) {
@@ -6326,7 +6325,8 @@ static const struct nla_policy
[NL80211_MESH_SETUP_AUTH_PROTOCOL] = { .type = NLA_U8 },
[NL80211_MESH_SETUP_USERSPACE_MPM] = { .type = NLA_FLAG },
[NL80211_MESH_SETUP_IE] = { .type = NLA_BINARY,
- .len = IEEE80211_MAX_DATA_LEN },
+ .len = IEEE80211_MAX_DATA_LEN,
+ .validate = validate_ie_attr },
[NL80211_MESH_SETUP_USERSPACE_AMPE] = { .type = NLA_FLAG },
};
@@ -6527,8 +6527,6 @@ static int nl80211_parse_mesh_setup(struct genl_info *info,
if (tb[NL80211_MESH_SETUP_IE]) {
struct nlattr *ieattr =
tb[NL80211_MESH_SETUP_IE];
- if (!is_valid_ie_attr(ieattr))
- return -EINVAL;
setup->ie = nla_data(ieattr);
setup->ie_len = nla_len(ieattr);
}
@@ -7161,9 +7159,6 @@ static int nl80211_trigger_scan(struct sk_buff *skb, struct genl_info *info)
int err, tmp, n_ssids = 0, n_channels, i;
size_t ie_len;
- if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
- return -EINVAL;
-
wiphy = &rdev->wiphy;
if (wdev->iftype == NL80211_IFTYPE_NAN)
@@ -7517,9 +7512,6 @@ nl80211_parse_sched_scan(struct wiphy *wiphy, struct wireless_dev *wdev,
struct nlattr *tb[NL80211_SCHED_SCAN_MATCH_ATTR_MAX + 1];
s32 default_match_rssi = NL80211_SCAN_RSSI_THOLD_OFF;
- if (!is_valid_ie_attr(attrs[NL80211_ATTR_IE]))
- return ERR_PTR(-EINVAL);
-
if (attrs[NL80211_ATTR_SCAN_FREQUENCIES]) {
n_channels = validate_scan_freqs(
attrs[NL80211_ATTR_SCAN_FREQUENCIES]);
@@ -8487,9 +8479,6 @@ static int nl80211_authenticate(struct sk_buff *skb, struct genl_info *info)
struct key_parse key;
bool local_state_change;
- if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
- return -EINVAL;
-
if (!info->attrs[NL80211_ATTR_MAC])
return -EINVAL;
@@ -8728,9 +8717,6 @@ static int nl80211_associate(struct sk_buff *skb, struct genl_info *info)
dev->ieee80211_ptr->conn_owner_nlportid != info->snd_portid)
return -EPERM;
- if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
- return -EINVAL;
-
if (!info->attrs[NL80211_ATTR_MAC] ||
!info->attrs[NL80211_ATTR_SSID] ||
!info->attrs[NL80211_ATTR_WIPHY_FREQ])
@@ -8854,9 +8840,6 @@ static int nl80211_deauthenticate(struct sk_buff *skb, struct genl_info *info)
dev->ieee80211_ptr->conn_owner_nlportid != info->snd_portid)
return -EPERM;
- if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
- return -EINVAL;
-
if (!info->attrs[NL80211_ATTR_MAC])
return -EINVAL;
@@ -8905,9 +8888,6 @@ static int nl80211_disassociate(struct sk_buff *skb, struct genl_info *info)
dev->ieee80211_ptr->conn_owner_nlportid != info->snd_portid)
return -EPERM;
- if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
- return -EINVAL;
-
if (!info->attrs[NL80211_ATTR_MAC])
return -EINVAL;
@@ -8982,9 +8962,6 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
memset(&ibss, 0, sizeof(ibss));
- if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
- return -EINVAL;
-
if (!info->attrs[NL80211_ATTR_SSID] ||
!nla_len(info->attrs[NL80211_ATTR_SSID]))
return -EINVAL;
@@ -9422,9 +9399,6 @@ static int nl80211_connect(struct sk_buff *skb, struct genl_info *info)
memset(&connect, 0, sizeof(connect));
- if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
- return -EINVAL;
-
if (!info->attrs[NL80211_ATTR_SSID] ||
!nla_len(info->attrs[NL80211_ATTR_SSID]))
return -EINVAL;
@@ -9655,8 +9629,6 @@ static int nl80211_update_connect_params(struct sk_buff *skb,
return -EOPNOTSUPP;
if (info->attrs[NL80211_ATTR_IE]) {
- if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
- return -EINVAL;
connect.ie = nla_data(info->attrs[NL80211_ATTR_IE]);
connect.ie_len = nla_len(info->attrs[NL80211_ATTR_IE]);
changed |= UPDATE_ASSOC_IES;
@@ -12308,8 +12280,7 @@ static int nl80211_update_ft_ies(struct sk_buff *skb, struct genl_info *info)
return -EOPNOTSUPP;
if (!info->attrs[NL80211_ATTR_MDID] ||
- !info->attrs[NL80211_ATTR_IE] ||
- !is_valid_ie_attr(info->attrs[NL80211_ATTR_IE]))
+ !info->attrs[NL80211_ATTR_IE])
return -EINVAL;
memset(&ft_params, 0, sizeof(ft_params));
--
2.14.4
^ permalink raw reply related
* [PATCH net-next 2/2] tcp: adjust rcv zerocopy hints based on frag sizes
From: Soheil Hassas Yeganeh @ 2018-09-26 20:57 UTC (permalink / raw)
To: davem, netdev; +Cc: edumazet, Soheil Hassas Yeganeh
In-Reply-To: <20180926205704.42754-1-soheil.kdev@gmail.com>
From: Soheil Hassas Yeganeh <soheil@google.com>
When SKBs are coalesced, we can have SKBs with different
frag sizes. Some with PAGE_SIZE and some not with PAGE_SIZE.
Since recv_skip_hint is always set to the full SKB size,
it can overestimate the amount that should be read using
normal read for coalesced packets.
Change the recv_skip_hint so that it only includes the first
frags that are not of PAGE_SIZE.
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 3e17501fc1a1..cdbd423bdeb4 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1805,8 +1805,17 @@ static int tcp_zerocopy_receive(struct sock *sk,
frags++;
}
}
- if (frags->size != PAGE_SIZE || frags->page_offset)
+ if (frags->size != PAGE_SIZE || frags->page_offset) {
+ int remaining = zc->recv_skip_hint;
+
+ while (remaining && (frags->size != PAGE_SIZE ||
+ frags->page_offset)) {
+ remaining -= frags->size;
+ frags++;
+ }
+ zc->recv_skip_hint -= remaining;
break;
+ }
ret = vm_insert_page(vma, address + length,
skb_frag_page(frags));
if (ret)
--
2.19.0.605.g01d371f741-goog
^ permalink raw reply related
* [PATCH net-next 1/2] tcp: set recv_skip_hint when tcp_inq is less than PAGE_SIZE
From: Soheil Hassas Yeganeh @ 2018-09-26 20:57 UTC (permalink / raw)
To: davem, netdev; +Cc: edumazet, Soheil Hassas Yeganeh
From: Soheil Hassas Yeganeh <soheil@google.com>
When we have less than PAGE_SIZE of data on receive queue,
we set recv_skip_hint to 0. Instead, set it to the actual
number of bytes available.
Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/tcp.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 69c236943f56..3e17501fc1a1 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1753,6 +1753,7 @@ static int tcp_zerocopy_receive(struct sock *sk,
struct vm_area_struct *vma;
struct sk_buff *skb = NULL;
struct tcp_sock *tp;
+ int inq;
int ret;
if (address & (PAGE_SIZE - 1) || address != zc->address)
@@ -1773,12 +1774,15 @@ static int tcp_zerocopy_receive(struct sock *sk,
tp = tcp_sk(sk);
seq = tp->copied_seq;
- zc->length = min_t(u32, zc->length, tcp_inq(sk));
+ inq = tcp_inq(sk);
+ zc->length = min_t(u32, zc->length, inq);
zc->length &= ~(PAGE_SIZE - 1);
-
- zap_page_range(vma, address, zc->length);
-
- zc->recv_skip_hint = 0;
+ if (zc->length) {
+ zap_page_range(vma, address, zc->length);
+ zc->recv_skip_hint = 0;
+ } else {
+ zc->recv_skip_hint = inq;
+ }
ret = 0;
while (length + PAGE_SIZE <= zc->length) {
if (zc->recv_skip_hint < PAGE_SIZE) {
--
2.19.0.605.g01d371f741-goog
^ 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