* [PATCH 4/9] kbuild: Add filechk2 function
From: Jiri Olsa @ 2018-04-05 15:16 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: lkml, netdev, linux-kbuild, Quentin Monnet, Eugene Syromiatnikov,
Jiri Benc, Stanislav Kozina, Jerome Marchand,
Arnaldo Carvalho de Melo, Masahiro Yamada, Michal Marek,
Jiri Kosina
In-Reply-To: <20180405151645.19130-1-jolsa@kernel.org>
Adding filechk2 function that has the same semantics
as filechk, but it takes the target file from the 2nd
argument instead of from the '$@' as in the filechk
function.
This function is needed when we can't have separate
target for the file, like in the following patch.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
scripts/Kbuild.include | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 065324a8046f..9775ce2771d4 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -67,6 +67,30 @@ define filechk
fi
endef
+# filechk2 is used to check if the content of a generated file is updated.
+# It follows the same logic as the filechk except instead of the $@ target
+# variable, the checked file is passed in 2nd argument.
+#
+# Sample usage:
+# define filechk_sample
+# echo $KERNELRELEASE
+# endef
+# version.h : Makefile
+# $(call filechk2,sample,version.h)
+# endef
+define filechk2
+ $(Q)set -e; \
+ $(kecho) ' CHK $(2)'; \
+ mkdir -p $(dir $(2)); \
+ $(filechk_$(1)) < $< > $(2).tmp; \
+ if [ -r $(2) ] && cmp -s $(2) $(2).tmp; then \
+ rm -f $(2).tmp; \
+ else \
+ $(kecho) ' UPD $(2)'; \
+ mv -f $(2).tmp $(2); \
+ fi
+endef
+
######
# gcc support functions
# See documentation in Documentation/kbuild/makefiles.txt
--
2.13.6
^ permalink raw reply related
* [PATCH 5/9] bpf: Add CONFIG_BUILDID_H option
From: Jiri Olsa @ 2018-04-05 15:16 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: lkml, netdev, linux-kbuild, Quentin Monnet, Eugene Syromiatnikov,
Jiri Benc, Stanislav Kozina, Jerome Marchand,
Arnaldo Carvalho de Melo, Masahiro Yamada, Michal Marek,
Jiri Kosina
In-Reply-To: <20180405151645.19130-1-jolsa@kernel.org>
Adding CONFIG_BUILDID_H option that forces build to generate
file with GNU build id value:
include/linux/buildid.h
It contains following macros:
#define LINUX_BUILDID_DATA "\x6c\x41\x0f\xea\xa9\x5d ...
#define LINUX_BUILDID_SIZE 20
Those macros will be used in following patches to identify
kernel in more precise way when loading eBPF program that
can touch kernel internal structures.
There's new build output for the check and update
of the buildid.h:
$ make
...
LD vmlinux.o
MODPOST vmlinux.o
KSYM .tmp_kallsyms1.o
KSYM .tmp_kallsyms2.o
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
CHK include/generated/uapi/linux/buildid.h
UPD include/generated/uapi/linux/buildid.h
...
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
Makefile | 12 ++++++++++++
init/Kconfig | 3 +++
scripts/Makefile | 1 +
| 42 ++++++++++++++++++++++++++++++++++++++++++
4 files changed, 58 insertions(+)
create mode 100644 scripts/extract-buildid.c
diff --git a/Makefile b/Makefile
index a65a3919c6ad..92b04d8f08bc 100644
--- a/Makefile
+++ b/Makefile
@@ -1023,6 +1023,15 @@ endif
include/generated/autoksyms.h: FORCE
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh true
+ifdef CONFIG_BUILDID_H
+buildid_h := include/linux/buildid.h
+
+define filechk_buildid.h
+ buildid=`readelf -n $@ | grep 'Build ID' | sed -e 's/^.*Build ID: \(.*\)$$/\1/'`; \
+ scripts/extract-buildid $$buildid
+endef
+endif
+
ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(SRCARCH)/Makefile.postlink)
# Final link of vmlinux with optional arch pass after final link
@@ -1032,6 +1041,9 @@ cmd_link-vmlinux = \
vmlinux: scripts/link-vmlinux.sh vmlinux_prereq $(vmlinux-deps) FORCE
+$(call if_changed,link-vmlinux)
+ifdef CONFIG_BUILDID_H
+ +$(call filechk2,buildid.h,$(buildid_h))
+endif
# Build samples along the rest of the kernel
ifdef CONFIG_SAMPLES
diff --git a/init/Kconfig b/init/Kconfig
index 2852692d7c9c..572df24dda9b 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1386,6 +1386,9 @@ config KALLSYMS_BASE_RELATIVE
# end of the "standard kernel features (expert users)" menu
+config BUILDID_H
+ bool
+
# syscall, maps, verifier
config BPF_SYSCALL
bool "Enable bpf() system call"
diff --git a/scripts/Makefile b/scripts/Makefile
index 25ab143cbe14..fa34eaed6c29 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -19,6 +19,7 @@ hostprogs-$(CONFIG_ASN1) += asn1_compiler
hostprogs-$(CONFIG_MODULE_SIG) += sign-file
hostprogs-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += extract-cert
hostprogs-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE) += insert-sys-cert
+hostprogs-$(CONFIG_BUILDID_H) += extract-buildid
HOSTCFLAGS_sortextable.o = -I$(srctree)/tools/include
HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
--git a/scripts/extract-buildid.c b/scripts/extract-buildid.c
new file mode 100644
index 000000000000..a116723da3ad
--- /dev/null
+++ b/scripts/extract-buildid.c
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/*
+ * Formats buildid into following macros:
+ *
+ * #define LINUX_BUILDID_DATA "\x6c\x41\x0f\xea\xa9\x5d\x46 ...
+ * #define LINUX_BUILDID_SIZE 20
+ *
+ */
+#include <string.h>
+#include <stdio.h>
+
+int main(int argc, char **argv)
+{
+ char *id;
+ int len, i;
+
+ if (argc != 2) {
+ fprintf(stderr, "usage: %s buildid\n", argv[0]);
+ return -1;
+ }
+
+ id = argv[1];
+ len = strlen(id);
+
+ printf("#ifndef _LINUX_BUILDID_H\n");
+ printf("#define _LINUX_BUILDID_H\n");
+ printf("\n");
+
+ printf("#define LINUX_BUILDID_DATA \"");
+
+ for (i = 0; i < len; i += 2)
+ printf("\\x%c%c", id[i], id[i + 1]);
+
+ printf("\"\n");
+
+ printf("#define LINUX_BUILDID_SIZE %u\n", len / 2);
+
+ printf("\n");
+ printf("#endif /* _LINUX_BUILDID_H */\n");
+ return 0;
+}
--
2.13.6
^ permalink raw reply related
* [PATCH 6/9] bpf: Add CONFIG_BPF_BUILDID_CHECK option
From: Jiri Olsa @ 2018-04-05 15:16 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: lkml, netdev, linux-kbuild, Quentin Monnet, Eugene Syromiatnikov,
Jiri Benc, Stanislav Kozina, Jerome Marchand,
Arnaldo Carvalho de Melo, Masahiro Yamada, Michal Marek,
Jiri Kosina
In-Reply-To: <20180405151645.19130-1-jolsa@kernel.org>
Adding CONFIG_BPF_BUILDID_CHECK option that forces kernel
to check on provided build id when loading eBPF program.
If the build id does not match the one in kernel the program
fails to load.
Adding new field into struct bpf_attr. The kern_buildid
points to the user memory that contains the buildid.
Kernel expose the notes section via sysfs, but there's
currently no other use for kernel's buildid, so I needed
to add new __init buildid_init function to parse it out.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
include/uapi/linux/bpf.h | 2 ++
init/Kconfig | 9 ++++++
kernel/bpf/syscall.c | 84 +++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 94 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index c5ec89732a8d..17d8d330e6c7 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -308,6 +308,8 @@ union bpf_attr {
* (context accesses, allowed helpers, etc).
*/
__u32 expected_attach_type;
+ /* Checked when prog_type=kprobe and CONFIG_BPF_BUILDID_CHECK. */
+ __aligned_u64 kern_buildid;
};
struct { /* anonymous struct used by BPF_OBJ_* commands */
diff --git a/init/Kconfig b/init/Kconfig
index 572df24dda9b..6d32220de7e0 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1406,6 +1406,15 @@ config BPF_JIT_ALWAYS_ON
Enables BPF JIT and removes BPF interpreter to avoid
speculative execution of BPF instructions by the interpreter
+config BPF_BUILDID_CHECK
+ bool "Check buildid for kprobe and tracepoint programs"
+ depends on BPF_SYSCALL
+ select BUILDID_H
+ default n
+ help
+ Enables BPF program load code to check on kernel Build ID
+ for kprobe programs.
+
config USERFAULTFD
bool "Enable userfaultfd() system call"
select ANON_INODES
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 0244973ee544..d0b3bc0bd9e6 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -1239,7 +1239,85 @@ static int bpf_prog_attach_check_attach_type(const struct bpf_prog *prog,
}
/* last field in 'union bpf_attr' used by this command */
-#define BPF_PROG_LOAD_LAST_FIELD expected_attach_type
+#define BPF_PROG_LOAD_LAST_FIELD kern_buildid
+
+#ifdef CONFIG_BPF_BUILDID_CHECK
+
+static struct {
+ const char *ptr;
+ int size;
+} buildid;
+
+#define BUILDID_MAX 40
+
+static int __check_buildid(union bpf_attr *attr)
+{
+ char id[buildid.size];
+
+ /* copy buildid from user space */
+ if (strncpy_from_user(id, u64_to_user_ptr(attr->kern_buildid),
+ buildid.size) < 0)
+ return -EFAULT;
+
+ return memcmp(id, buildid.ptr, buildid.size);
+}
+
+static int check_buildid(union bpf_attr *attr)
+{
+ return buildid.ptr ? __check_buildid(attr) : 0;
+}
+
+#define NT_ALIGN(n) (((n) + 3) & ~3)
+#define NT_GNU_BUILD_ID 3
+
+extern const void __start_notes __weak;
+extern const void __stop_notes __weak;
+
+static int __init buildid_init(void)
+{
+ const void *ptr = &__start_notes;
+
+ while (ptr < &__stop_notes) {
+ const Elf64_Nhdr *nhdr = ptr;
+ size_t namesz = NT_ALIGN(nhdr->n_namesz),
+ descsz = NT_ALIGN(nhdr->n_descsz);
+ const char *name;
+
+ ptr += sizeof(*nhdr);
+ name = ptr;
+ ptr += namesz;
+
+ if (nhdr->n_type != NT_GNU_BUILD_ID ||
+ nhdr->n_namesz != sizeof("GNU") ||
+ memcmp(name, "GNU", sizeof("GNU"))) {
+ ptr += descsz;
+ continue;
+ }
+
+ buildid.ptr = ptr;
+ buildid.size = descsz;
+ break;
+ }
+
+ /* Sanity checks on the parsed buildid. */
+ if (!buildid.ptr) {
+ pr_warn("bpf: GNU buildid not found, switching off the check\n");
+ } else if (buildid.size > 64) {
+ pr_warn("bpf: GNU buildid too long, switching off the check\n");
+ buildid.ptr = NULL;
+ }
+
+ return 0;
+}
+
+subsys_initcall(buildid_init);
+
+#else
+static int check_buildid(union bpf_attr *attr __maybe_unused)
+{
+ return 0;
+}
+#endif /* CONFIG_BPF_BUILDID_CHECK */
static int bpf_prog_load(union bpf_attr *attr)
{
@@ -1271,6 +1349,10 @@ static int bpf_prog_load(union bpf_attr *attr)
attr->kern_version != LINUX_VERSION_CODE)
return -EINVAL;
+ if (type == BPF_PROG_TYPE_KPROBE &&
+ check_buildid(attr))
+ return -EINVAL;
+
if (type != BPF_PROG_TYPE_SOCKET_FILTER &&
type != BPF_PROG_TYPE_CGROUP_SKB &&
!capable(CAP_SYS_ADMIN))
--
2.13.6
^ permalink raw reply related
* [PATCH 7/9] libbpf: Synchronize uapi bpf.h header
From: Jiri Olsa @ 2018-04-05 15:16 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: lkml, netdev, linux-kbuild, Quentin Monnet, Eugene Syromiatnikov,
Jiri Benc, Stanislav Kozina, Jerome Marchand,
Arnaldo Carvalho de Melo, Masahiro Yamada, Michal Marek,
Jiri Kosina
In-Reply-To: <20180405151645.19130-1-jolsa@kernel.org>
Synchronize include/uapi/linux/bpf.h with tools version.
Link: http://lkml.kernel.org/n/tip-gaja0nnet6oku657642nxnaf@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
tools/include/uapi/linux/bpf.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 9d07465023a2..17d8d330e6c7 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -308,6 +308,8 @@ union bpf_attr {
* (context accesses, allowed helpers, etc).
*/
__u32 expected_attach_type;
+ /* Checked when prog_type=kprobe and CONFIG_BPF_BUILDID_CHECK. */
+ __aligned_u64 kern_buildid;
};
struct { /* anonymous struct used by BPF_OBJ_* commands */
@@ -864,6 +866,7 @@ enum bpf_func_id {
/* BPF_FUNC_skb_set_tunnel_key flags. */
#define BPF_F_ZERO_CSUM_TX (1ULL << 1)
#define BPF_F_DONT_FRAGMENT (1ULL << 2)
+#define BPF_F_SEQ_NUMBER (1ULL << 3)
/* BPF_FUNC_perf_event_output, BPF_FUNC_perf_event_read and
* BPF_FUNC_perf_event_read_value flags.
--
2.13.6
^ permalink raw reply related
* [PATCH 8/9] libbpf: Add support to attach buildid to program load
From: Jiri Olsa @ 2018-04-05 15:16 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: lkml, netdev, linux-kbuild, Quentin Monnet, Eugene Syromiatnikov,
Jiri Benc, Stanislav Kozina, Jerome Marchand,
Arnaldo Carvalho de Melo, Masahiro Yamada, Michal Marek,
Jiri Kosina
In-Reply-To: <20180405151645.19130-1-jolsa@kernel.org>
Adding support to retrieve buildid from elf's "buildid"
section and passing it through to the load_program
function to kernel bpf syscall.
Fixing perf use of the bpf_load_program function and
linking in the vsprintf.o into bpftool to have the
scnprintf function in.
Link: http://lkml.kernel.org/n/tip-2pafwtzbyosmf9ftuf0udn54@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
tools/bpf/bpftool/Makefile | 5 ++++-
tools/lib/bpf/bpf.c | 6 ++++--
tools/lib/bpf/bpf.h | 5 +++--
tools/lib/bpf/libbpf.c | 46 ++++++++++++++++++++++++++++++++++++++++------
tools/perf/tests/bpf.c | 9 ++++++++-
5 files changed, 59 insertions(+), 12 deletions(-)
diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index 4e69782c4a79..9ac11ea5de1c 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -75,11 +75,14 @@ include $(wildcard $(OUTPUT)*.d)
all: $(OUTPUT)bpftool
SRCS = $(wildcard *.c)
-OBJS = $(patsubst %.c,$(OUTPUT)%.o,$(SRCS)) $(OUTPUT)disasm.o
+OBJS = $(patsubst %.c,$(OUTPUT)%.o,$(SRCS)) $(OUTPUT)disasm.o $(OUTPUT)vsprintf.o
$(OUTPUT)disasm.o: $(srctree)/kernel/bpf/disasm.c
$(QUIET_CC)$(COMPILE.c) -MMD -o $@ $<
+$(OUTPUT)vsprintf.o: $(srctree)/tools/lib/vsprintf.c
+ $(QUIET_CC)$(COMPILE.c) -MMD -o $@ $<
+
$(OUTPUT)bpftool: $(OBJS) $(LIBBPF)
$(QUIET_LINK)$(CC) $(CFLAGS) -o $@ $^ $(LIBS)
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index acbb3f8b3bec..8e384db5bbbd 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -168,6 +168,7 @@ int bpf_load_program_xattr(const struct bpf_load_program_attr *load_attr,
attr.log_size = 0;
attr.log_level = 0;
attr.kern_version = load_attr->kern_version;
+ attr.kern_buildid = ptr_to_u64(load_attr->buildid);
memcpy(attr.prog_name, load_attr->name,
min(name_len, BPF_OBJ_NAME_LEN - 1));
@@ -185,8 +186,8 @@ int bpf_load_program_xattr(const struct bpf_load_program_attr *load_attr,
int bpf_load_program(enum bpf_prog_type type, const struct bpf_insn *insns,
size_t insns_cnt, const char *license,
- __u32 kern_version, char *log_buf,
- size_t log_buf_sz)
+ __u32 kern_version, const char *buildid,
+ char *log_buf, size_t log_buf_sz)
{
struct bpf_load_program_attr load_attr;
@@ -198,6 +199,7 @@ int bpf_load_program(enum bpf_prog_type type, const struct bpf_insn *insns,
load_attr.insns_cnt = insns_cnt;
load_attr.license = license;
load_attr.kern_version = kern_version;
+ load_attr.buildid = buildid;
return bpf_load_program_xattr(&load_attr, log_buf, log_buf_sz);
}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 39f6a0d64a3b..b5ffb178ebdd 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -49,6 +49,7 @@ struct bpf_load_program_attr {
size_t insns_cnt;
const char *license;
__u32 kern_version;
+ const char *buildid;
};
/* Recommend log buffer size */
@@ -57,8 +58,8 @@ int bpf_load_program_xattr(const struct bpf_load_program_attr *load_attr,
char *log_buf, size_t log_buf_sz);
int bpf_load_program(enum bpf_prog_type type, const struct bpf_insn *insns,
size_t insns_cnt, const char *license,
- __u32 kern_version, char *log_buf,
- size_t log_buf_sz);
+ __u32 kern_version, const char *buildid,
+ char *log_buf, size_t log_buf_sz);
int bpf_verify_program(enum bpf_prog_type type, const struct bpf_insn *insns,
size_t insns_cnt, int strict_alignment,
const char *license, __u32 kern_version,
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 5922443063f0..421f2c2e0ebe 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -220,6 +220,7 @@ static LIST_HEAD(bpf_objects_list);
struct bpf_object {
char license[64];
+ char buildid[64];
u32 kern_version;
struct bpf_program *programs;
@@ -599,6 +600,32 @@ bpf_object__init_kversion(struct bpf_object *obj,
return 0;
}
+static void buildid_scnprint(char *buf, int n, char *buildid, int size)
+{
+ int i, ret = 0;
+
+ for (i = 0; i < size; i++) {
+ ret += scnprintf(buf + ret, n - ret, "%x",
+ (unsigned char) buildid[i]);
+ }
+}
+
+static int
+bpf_object__init_buildid(struct bpf_object *obj,
+ void *data, size_t size)
+{
+ char buf[64];
+
+ if (size > sizeof(obj->buildid))
+ return -LIBBPF_ERRNO__FORMAT;
+
+ memcpy(&obj->buildid, data, size);
+
+ buildid_scnprint(buf, 64, obj->buildid, size);
+ pr_debug("kernel buildid of %s is: %s\n", obj->path, buf);
+ return 0;
+}
+
static int compare_bpf_map(const void *_a, const void *_b)
{
const struct bpf_map *a = _a;
@@ -817,6 +844,10 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
err = bpf_object__init_kversion(obj,
data->d_buf,
data->d_size);
+ else if (strcmp(name, "buildid") == 0)
+ err = bpf_object__init_buildid(obj,
+ data->d_buf,
+ data->d_size);
else if (strcmp(name, "maps") == 0)
obj->efile.maps_shndx = idx;
else if (sh.sh_type == SHT_SYMTAB) {
@@ -1166,7 +1197,7 @@ static int bpf_object__collect_reloc(struct bpf_object *obj)
static int
load_program(enum bpf_prog_type type, enum bpf_attach_type expected_attach_type,
const char *name, struct bpf_insn *insns, int insns_cnt,
- char *license, u32 kern_version, int *pfd)
+ char *license, u32 kern_version, const char *buildid, int *pfd)
{
struct bpf_load_program_attr load_attr;
char *log_buf;
@@ -1180,6 +1211,7 @@ load_program(enum bpf_prog_type type, enum bpf_attach_type expected_attach_type,
load_attr.insns_cnt = insns_cnt;
load_attr.license = license;
load_attr.kern_version = kern_version;
+ load_attr.buildid = buildid;
if (!load_attr.insns || !load_attr.insns_cnt)
return -EINVAL;
@@ -1189,7 +1221,6 @@ load_program(enum bpf_prog_type type, enum bpf_attach_type expected_attach_type,
pr_warning("Alloc log buffer for bpf loader error, continue without log\n");
ret = bpf_load_program_xattr(&load_attr, log_buf, BPF_LOG_BUF_SIZE);
-
if (ret >= 0) {
*pfd = ret;
ret = 0;
@@ -1234,7 +1265,8 @@ load_program(enum bpf_prog_type type, enum bpf_attach_type expected_attach_type,
static int
bpf_program__load(struct bpf_program *prog,
- char *license, u32 kern_version)
+ char *license, u32 kern_version,
+ const char *buildid)
{
int err = 0, fd, i;
@@ -1261,7 +1293,7 @@ bpf_program__load(struct bpf_program *prog,
}
err = load_program(prog->type, prog->expected_attach_type,
prog->name, prog->insns, prog->insns_cnt,
- license, kern_version, &fd);
+ license, kern_version, buildid, &fd);
if (!err)
prog->instances.fds[0] = fd;
goto out;
@@ -1292,7 +1324,8 @@ bpf_program__load(struct bpf_program *prog,
err = load_program(prog->type, prog->expected_attach_type,
prog->name, result.new_insn_ptr,
result.new_insn_cnt,
- license, kern_version, &fd);
+ license, kern_version,
+ buildid, &fd);
if (err) {
pr_warning("Loading the %dth instance of program '%s' failed\n",
@@ -1324,7 +1357,8 @@ bpf_object__load_progs(struct bpf_object *obj)
continue;
err = bpf_program__load(&obj->programs[i],
obj->license,
- obj->kern_version);
+ obj->kern_version,
+ obj->buildid);
if (err)
return err;
}
diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
index 79b54f8ddebf..2a738b7b743a 100644
--- a/tools/perf/tests/bpf.c
+++ b/tools/perf/tests/bpf.c
@@ -298,6 +298,7 @@ static int check_env(void)
int err;
unsigned int kver_int;
char license[] = "GPL";
+ char buildid[64];
struct bpf_insn insns[] = {
BPF_MOV64_IMM(BPF_REG_0, 1),
@@ -310,9 +311,15 @@ static int check_env(void)
return err;
}
+ err = fetch_kernel_buildid(buildid, sizeof(buildid));
+ if (err) {
+ pr_debug("Unable to get kernel buildid\n");
+ return err;
+ }
+
err = bpf_load_program(BPF_PROG_TYPE_KPROBE, insns,
sizeof(insns) / sizeof(insns[0]),
- license, kver_int, NULL, 0);
+ license, kver_int, buildid, NULL, 0);
if (err < 0) {
pr_err("Missing basic BPF support, skip this test: %s\n",
strerror(errno));
--
2.13.6
^ permalink raw reply related
* [PATCH 9/9] perf tools: The buildid usage in example eBPF program
From: Jiri Olsa @ 2018-04-05 15:16 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann
Cc: lkml, netdev, linux-kbuild, Quentin Monnet, Eugene Syromiatnikov,
Jiri Benc, Stanislav Kozina, Jerome Marchand,
Arnaldo Carvalho de Melo, Masahiro Yamada, Michal Marek,
Jiri Kosina
In-Reply-To: <20180405151645.19130-1-jolsa@kernel.org>
The bpf-samples/bpf-stdout-example.c demonstrates how to put the
buildid data into eBPF program.
Link: http://lkml.kernel.org/n/tip-dq97ddil7h3qbvphbbo8p08c@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
tools/perf/bpf-samples/bpf-stdout-example.c | 42 +++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100644 tools/perf/bpf-samples/bpf-stdout-example.c
diff --git a/tools/perf/bpf-samples/bpf-stdout-example.c b/tools/perf/bpf-samples/bpf-stdout-example.c
new file mode 100644
index 000000000000..60783442bd5c
--- /dev/null
+++ b/tools/perf/bpf-samples/bpf-stdout-example.c
@@ -0,0 +1,42 @@
+#include <uapi/linux/bpf.h>
+#include <linux/buildid.h>
+
+#define SEC(NAME) __attribute__((section(NAME), used))
+
+char _license[] SEC("license") = "GPL";
+int _version SEC("version") = LINUX_VERSION_CODE;
+char _buildid[] SEC("buildid") = LINUX_BUILDID_DATA;
+
+static unsigned long long (*bpf_get_smp_processor_id)(void) =
+ (void *) BPF_FUNC_get_smp_processor_id;
+static int (*bpf_perf_event_output)(void *ctx, void *map,
+ unsigned long long flags, void *data,
+ int size) =
+ (void *) BPF_FUNC_perf_event_output;
+
+struct bpf_map_def {
+ unsigned int type;
+ unsigned int key_size;
+ unsigned int value_size;
+ unsigned int max_entries;
+ unsigned int map_flags;
+ unsigned int inner_map_idx;
+ unsigned int numa_node;
+};
+
+struct bpf_map_def SEC("maps") __bpf_stdout__ = {
+ .type = BPF_MAP_TYPE_PERF_EVENT_ARRAY,
+ .key_size = sizeof(int),
+ .value_size = sizeof(u32),
+ .max_entries = __NR_CPUS__,
+};
+
+SEC("probe=sys_read")
+int func(void *ctx)
+{
+ char output_str[] = "Raise a BPF event!";
+
+ bpf_perf_event_output(ctx, &__bpf_stdout__, bpf_get_smp_processor_id(),
+ &output_str, sizeof(output_str));
+ return 0;
+}
--
2.13.6
^ permalink raw reply related
* Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: Andrew Lunn @ 2018-04-05 15:23 UTC (permalink / raw)
To: Laurentiu Tudor
Cc: Stuart Yoder, Arnd Bergmann, Ioana Ciornei, gregkh,
Linux Kernel Mailing List, Ruxandra Ioana Ciocoi Radulescu,
Razvan Stefanescu, Roy Pledge, Networking
In-Reply-To: <5AC63610.4000504@nxp.com>
On Thu, Apr 05, 2018 at 02:43:29PM +0000, Laurentiu Tudor wrote:
> Hi Andrew,
>
> On 04/05/2018 03:48 PM, Andrew Lunn wrote:
> >>> Hi Laurentiu
> >>>
> >>> So i can use switchdev without it? I can modprobe the switchdev
> >>> driver, all the physical interfaces will appear, and i can use ip addr
> >>> add etc. I do not need to use a user space tool at all in order to use
> >>> the network functionality?
> >>
> >> Absolutely!
> >
> > Great.
> >
> > Then the easiest way forwards is to simply drop the IOCTL code for the
> > moment. Get the basic support for the hardware into the kernel
> > first. Then come back later to look at dynamic behaviour which needs
> > some form of configuration.
>
> Hmm, not sure I understand. We already have a fully functional ethernet
> driver [1] and a switch driver [2] ...
In staging, the tree of crap. You want to get it out of there and into
the main tree. But that effort is being side lined by the discussion
around this IOCTL call. The best way forward is to to accept Greg is
not going to take this patchset at the moment, and move on. As you
said, it is not needed for the Ethernet and switchdev driver.
What needs to happen before the Ethernet driver can be reviewed for
moving out of staging?
Andrew
^ permalink raw reply
* Kernel bug from adding bpf actions in tc
From: Lucas Bates @ 2018-04-05 15:23 UTC (permalink / raw)
To: dcaratti; +Cc: Linux Kernel Network Developers
Hi Davide,
Our overnight tc test runs of net-next revealed a kernel bug on one of
the BPF tests you submitted, d959. The add action completes
successfully, but the bug occurs on the verify when tdc does a get of
the action that was just added. Here's the text of the dump:
[ 61.973632] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000020
[ 61.974366] PGD 8000000081881067 P4D 8000000081881067 PUD 83784067 PMD 0
[ 61.974986] Oops: 0000 [#1] SMP PTI
[ 61.975309] Modules linked in: kvm_intel kvm irqbypass
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel
aes_x86_64 crypto_simd psmouse glue_helper cryptd serio_raw
[ 61.976800] CPU: 28 PID: 1087 Comm: tc Not tainted 4.16.0+ #28
[ 61.977329] RIP: 0010:__bpf_prog_put+0x5/0xe0
[ 61.977731] RSP: 0018:ffff9647c4823788 EFLAGS: 00010202
[ 61.978204] RAX: 0000000000000000 RBX: ffff9647c48237a0 RCX: 000000000000176c
[ 61.978845] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
[ 61.979484] RBP: 0000000000000000 R08: 0000000000025be0 R09: ffffffffa4794077
[ 61.980121] R10: ffffdc1bc2130b00 R11: 0000000000000000 R12: 0000000000000000
[ 61.980763] R13: 0000000000000001 R14: ffff8889869969f0 R15: 00000000ffffffea
[ 61.981398] FS: 00007faa72489700(0000) GS:ffff888988f00000(0000)
knlGS:0000000000000000
[ 61.982114] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 61.982627] CR2: 0000000000000020 CR3: 0000000085938004 CR4: 00000000003606a0
[ 61.983263] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 61.983897] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 61.984531] Call Trace:
[ 61.984766] tcf_bpf_cfg_cleanup+0x2f/0x40
[ 61.985139] tcf_bpf_cleanup+0x3c/0x50
[ 61.985479] ? uncore_event_cpu_online+0x80/0x3c0
[ 61.985922] __tcf_idr_release+0x72/0x150
[ 61.986297] tcf_bpf_init+0x102/0x3e0
[ 61.986637] ? perf_trace_sched_process_exec+0xf4/0x140
[ 61.987108] tcf_action_init_1+0x36c/0x410
[ 61.987482] ? ___slab_alloc+0x218/0x4b0
[ 61.987841] tcf_action_init+0x106/0x190
[ 61.988204] tc_ctl_action+0x11a/0x220
[ 61.988551] rtnetlink_rcv_msg+0x243/0x2f0
[ 61.988931] ? _cond_resched+0x16/0x40
[ 61.989277] ? __kmalloc_node_track_caller+0x1e6/0x2a0
[ 61.989746] ? rtnl_calcit.isra.29+0xe0/0xe0
[ 61.990137] netlink_rcv_skb+0xde/0x110
[ 61.990494] netlink_unicast+0x16d/0x220
[ 61.990858] netlink_sendmsg+0x293/0x370
[ 61.991224] sock_sendmsg+0x36/0x40
[ 61.991559] ___sys_sendmsg+0x2cb/0x2e0
[ 61.991913] ? pagecache_get_page+0x27/0x220
[ 61.992302] ? filemap_fault+0xa2/0x650
[ 61.992651] ? page_add_file_rmap+0x108/0x200
[ 61.993057] ? alloc_set_pte+0x2aa/0x530
[ 61.993419] ? finish_fault+0x4e/0x70
[ 61.993758] ? __handle_mm_fault+0xbfc/0x1110
[ 61.994160] ? __sys_sendmsg+0x53/0x80
[ 61.994506] __sys_sendmsg+0x53/0x80
[ 61.994849] do_syscall_64+0x6e/0x120
[ 61.995189] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 61.995662] RIP: 0033:0x7faa71885bd0
[ 61.995991] RSP: 002b:00007ffccf65bf28 EFLAGS: 00000246 ORIG_RAX:
000000000000002e
[ 61.996693] RAX: ffffffffffffffda RBX: 00007ffccf65c050 RCX: 00007faa71885bd0
[ 61.997350] RDX: 0000000000000000 RSI: 00007ffccf65bfa0 RDI: 0000000000000003
[ 61.998001] RBP: 000000005ac513e0 R08: 0000000000000001 R09: 0000000000000000
[ 61.998649] R10: 00000000000005e7 R11: 0000000000000246 R12: 0000000000000000
[ 61.999287] R13: 00007ffccf6600b0 R14: 0000000000000001 R15: 0000000000674600
[ 61.999942] Code: c6 72 00 48 8b 43 20 48 c7 c7 d0 61 9b a5 c7 40
10 00 00 00 00 5b e9 1b d9 74 00 90 66 2e 0f 1f 84 00 00 00 00 00 66
66 66 66 90 <48> 8b 47 20 f0 ff 08 74 01 c3 41 54 41 89 f4 55 48 89 fd
53 66
[ 62.001660] RIP: __bpf_prog_put+0x5/0xe0 RSP: ffff9647c4823788
[ 62.002183] CR2: 0000000000000020
[ 62.002488] ---[ end trace 19b56d1a66dd8e2a ]---
I'm sending this your way because you were the last one to touch this
part of the code. Have you seen this in your own testing? (This
can't be replicated by hand, only by running tdc).
- Lucas
^ permalink raw reply
* Re: [virtio-dev] Re: [RFC PATCH 1/3] qemu: virtio-bypass should explicitly bind to a passthrough device
From: Paolo Bonzini @ 2018-04-05 15:31 UTC (permalink / raw)
To: Siwei Liu, Michael S. Tsirkin
Cc: Si-Wei Liu, Jiri Pirko, Stephen Hemminger, Alexander Duyck,
David Miller, Brandeburg, Jesse, Jakub Kicinski, Jason Wang,
Samudrala, Sridhar, Netdev, virtualization, virtio-dev
In-Reply-To: <CADGSJ23jr7xrq8h9rFHLtXkbpsB+AK8wcUzOQnpeftbhiYdOvA@mail.gmail.com>
On 04/04/2018 10:02, Siwei Liu wrote:
>> pci_bus_num is almost always a bug if not done within
>> a context of a PCI host, bridge, etc.
>>
>> In particular this will not DTRT if run before guest assigns bus
>> numbers.
>>
> I was seeking means to reserve a specific pci bus slot from drivers,
> and update the driver when guest assigns the bus number but it seems
> there's no low-hanging fruits. Because of that reason the bus_num is
> only obtained until it's really needed (during get_config) and I
> assume at that point the pci bus assignment is already done. I know
> the current one is not perfect, but we need that information (PCI
> bus:slot.func number) to name the guest device correctly.
Can you use the -device "id", and look it up as
devices = container_get(qdev_get_machine(), "/peripheral");
return object_resolve_path_component(devices, id);
?
Thanks,
Paolo
^ permalink raw reply
* RE: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: Ruxandra Ioana Ciocoi Radulescu @ 2018-04-05 15:35 UTC (permalink / raw)
To: Andrew Lunn, Laurentiu Tudor
Cc: Stuart Yoder, Arnd Bergmann, Ioana Ciornei, gregkh,
Linux Kernel Mailing List, Razvan Stefanescu, Roy Pledge,
Networking
In-Reply-To: <20180405152348.GC32663@lunn.ch>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Thursday, April 5, 2018 6:24 PM
> To: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> Cc: Stuart Yoder <stuyoder@gmail.com>; Arnd Bergmann <arnd@arndb.de>;
> Ioana Ciornei <ioana.ciornei@nxp.com>; gregkh
> <gregkh@linuxfoundation.org>; Linux Kernel Mailing List <linux-
> kernel@vger.kernel.org>; Ruxandra Ioana Ciocoi Radulescu
> <ruxandra.radulescu@nxp.com>; Razvan Stefanescu
> <razvan.stefanescu@nxp.com>; Roy Pledge <roy.pledge@nxp.com>;
> Networking <netdev@vger.kernel.org>
> Subject: Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
>
> On Thu, Apr 05, 2018 at 02:43:29PM +0000, Laurentiu Tudor wrote:
> > Hi Andrew,
> >
> > On 04/05/2018 03:48 PM, Andrew Lunn wrote:
> > >>> Hi Laurentiu
> > >>>
> > >>> So i can use switchdev without it? I can modprobe the switchdev
> > >>> driver, all the physical interfaces will appear, and i can use ip addr
> > >>> add etc. I do not need to use a user space tool at all in order to use
> > >>> the network functionality?
> > >>
> > >> Absolutely!
> > >
> > > Great.
> > >
> > > Then the easiest way forwards is to simply drop the IOCTL code for the
> > > moment. Get the basic support for the hardware into the kernel
> > > first. Then come back later to look at dynamic behaviour which needs
> > > some form of configuration.
> >
> > Hmm, not sure I understand. We already have a fully functional ethernet
> > driver [1] and a switch driver [2] ...
>
> In staging, the tree of crap. You want to get it out of there and into
> the main tree. But that effort is being side lined by the discussion
> around this IOCTL call. The best way forward is to to accept Greg is
> not going to take this patchset at the moment, and move on. As you
> said, it is not needed for the Ethernet and switchdev driver.
>
> What needs to happen before the Ethernet driver can be reviewed for
> moving out of staging?
Hi Andrew,
We're waiting for the DPIO driver (which we depend on) to be moved
out of staging first, it's currently under review:
https://lkml.org/lkml/2018/3/27/1086
Ioana
^ permalink raw reply
* [PATCH] qtnfmac: pearl: pcie: fix memory leak in qtnf_fw_work_handler
From: Gustavo A. R. Silva @ 2018-04-05 15:49 UTC (permalink / raw)
To: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Gustavo A. R. Silva
In case memory resources for fw were succesfully allocated, release
them before jumping to fw_load_fail.
Addresses-Coverity-ID: 1466092 ("Resource leak")
Fixes: c3b2f7ca4186 ("qtnfmac: implement asynchronous firmware loading")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
index f117904..6c1e139 100644
--- a/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
+++ b/drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c
@@ -1185,6 +1185,10 @@ static void qtnf_fw_work_handler(struct work_struct *work)
if (qtnf_poll_state(&priv->bda->bda_ep_state, QTN_EP_FW_LOADRDY,
QTN_FW_DL_TIMEOUT_MS)) {
pr_err("card is not ready\n");
+
+ if (!flashboot)
+ release_firmware(fw);
+
goto fw_load_fail;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 3/9] kbuild: Do not pass arguments to link-vmlinux.sh
From: Masahiro Yamada @ 2018-04-05 15:50 UTC (permalink / raw)
To: Jiri Olsa
Cc: Alexei Starovoitov, Daniel Borkmann, lkml, netdev,
Linux Kbuild mailing list, Quentin Monnet, Eugene Syromiatnikov,
Jiri Benc, Stanislav Kozina, Jerome Marchand,
Arnaldo Carvalho de Melo, Michal Marek, Jiri Kosina
In-Reply-To: <20180405151645.19130-4-jolsa@kernel.org>
2018-04-06 0:16 GMT+09:00 Jiri Olsa <jolsa@kernel.org>:
> There's no need to pass LD* arguments to link-vmlinux.sh,
> because they are passed as variables. The only argument
> the link-vmlinux.sh supports is the 'clean' argument.
>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
Wrong.
$(LD) $(LDFLAGS) $(LDFLAGS_vmlinux)
exist here so that any change in them
invokes scripts/linkk-vmlinux.sh
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index d3300e46f925..a65a3919c6ad 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1027,7 +1027,7 @@ ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(SRCARCH)/Makefile.postlink)
>
> # Final link of vmlinux with optional arch pass after final link
> cmd_link-vmlinux = \
> - $(CONFIG_SHELL) $< $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) ; \
> + $(CONFIG_SHELL) $< ; \
> $(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
>
> vmlinux: scripts/link-vmlinux.sh vmlinux_prereq $(vmlinux-deps) FORCE
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications
From: Jiong Wang @ 2018-04-05 15:50 UTC (permalink / raw)
To: Alexei Starovoitov, Edward Cree; +Cc: Daniel Borkmann, netdev
In-Reply-To: <20180403010802.jkqffxw4m75oioj7@ast-mbp>
On 03/04/2018 02:08, Alexei Starovoitov wrote:
> Combining subprog pass with do_check is going into opposite direction
> of this long term work. Divide and conquer. Combining more things into
> do_check is the opposite of this programming principle.
Agree. And for the redundant insn traversal issue in check_subprogs that
Edward trying to fix, I am thinking we could do it by utilizing the
existing DFS traversal in check_cfg.
The current DFS probably could be improved into an generic instruction
information collection pass.
This won't make the existing DFS complexer as it only does information
collection as a side job during traversal. These collected information
then could be used to build any other information to be consumed later,
for example subprog, basic blocks etc.
For the redundant insn traversal issue during subprog detection, the
Like how we mark STATE_LIST_MARK in DFS, we could just call add_subprog
for BPF_PSEUDO_CALL insn during DFS.
i.e we change the code logic of check_cfg into:
check_cfg
{
* DFS traversal:
- detect back-edge.
- collect STATE_LIST_MARK.
- collect subprog destination.
* check all insns are reachable.
* check_subprogs (insn traversal removed).
}
I prototyped a patch for above change, the change looks to me is easier to
review. There are 8 regressions on selftests however after this change due
to check_subprogs moved after some checks in DFS that some errors detected
before the expected errors, need to be cleaned up.
Does this direction sound good?
And if we want to build basic-block later, we could just call a new add_bb
(similar as add_subprog) for jump targets etc. (some of those places are
actually STATE_LIST_MARK_JMPTARGET if we separate STATE_LIST_MARK as
STATE_LIST_MARK_JMPTARGET and STATE_LIST_MARK_HEURISTIC).
Regards,
Jiong
^ permalink raw reply
* Re: [RFC] ethtool: Support for driver private ioctl's
From: Florian Fainelli @ 2018-04-05 15:50 UTC (permalink / raw)
To: Jose Abreu, David Miller, Jakub Jelinek, Jeff Garzik, Tim Hockin,
Eli Kupermann, Chris Leech, Scott Feldman, Ben Hutchings
Cc: netdev, Joao Pinto
In-Reply-To: <cbd05f37-509b-118b-e681-0ccd0ebebd73@synopsys.com>
On 04/05/2018 03:47 AM, Jose Abreu wrote:
> Hi All,
>
> I would like to know your opinion regarding adding support for
> driver private ioctl's in ethtool.
>
> Background: Synopsys Ethernet IP's have a certain number of
> features which can be reconfigured at runtime. Giving you two
> examples: One of the most recent one is the safety features,
> which can be enabled/disabled and forced at runtime. Another one
> is a Flexible RX Parser which can route specific packets to
> specific RX DMA channels. Given that these are features specific
> to our IP's it would not be useful to add an uniform API for this
> because the users would only be one or two drivers ...
Parsing of packets and directing the matched packets to specific
queues/channels can be done through ethtool rxnfc API, tc/cls_flower as
well, so you should really check whether those APIs don't already allow
you to do what you want.
ethtool already supports a concept of private flags, not ioctl() though
which allows you to toggle boolean values for instance (or technically
up to how many bits a "flag" is used to represent) is that enough or do
you need to turn on/off the feature as well as pass configuration
parameters?
>
> This new feature would change the help usage for ethtool so that
> each driver private option would be shown, and then each driver
> specific file would have a structure with all the available
> options. Finally, each driver would have to handle the private
> IOCTL's.
>
> We already have this working locally and now I would like to know
> your opinion about upstreaming this ... Do you think this can be
> useful for anyone else? Or should we change direction to use, for
> example, debugfs/configfs?
In general, even if there is only one driver implementing a particular
feature, the approach chosen is to come up with an API that is as
generic as possible. Even if there is a single user of that API in tree,
having something that was thought to be generic is better than allowing
uncontrolled private ioctl() implementations.
--
Florian
^ permalink raw reply
* Re: marvell switch
From: Ran Shalit @ 2018-04-05 15:59 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev
In-Reply-To: <20180405122223.GC12178@lunn.ch>
On Thu, Apr 5, 2018 at 3:22 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Thu, Apr 05, 2018 at 05:47:24AM +0300, Ran Shalit wrote:
>> Hello,
>>
>> I am trying to use marvell switch in linux,
>> Is it that the kernel drivers from marvell switch are used just to
>> enable all ports, or do they also provide APIs to userspace to enable
>> specific ports only.
>> I have not find examples or wiki for marvell switch, so I am not too
>> sure as what are the drivers meant for.
>
> Hi Ran
>
> The Marvell driver makes each port act like a normal Linux network
> interface. So if you want to enable a port, do
>
> ip link set lan0 up
>
> Want to add an ip address to a port
>
> ip addr add 10.42.42.42/24 dev lan0
>
> Want to bridge two ports
>
> ip link add name br0 type bridge
> ip link set dev br0 up
> ip link set dev lan0 master br0
> ip link set dev lan1 master br0
>
> Just treat them as normal interfaces.
>
Is there a wiki which explains switch configuration ?
What does it mean that they are treated as normal interfaces ?
Is it possible to open socket and send/recieve on switch ports (lan0
for example) ?
My understanding is that these ports are not treated the same as eth0
interface for example.
Thanks for the assistance,
ranran
> Andrew
^ permalink raw reply
* Re: [PATCH 1/2] net: phy: Helper function for reading strapped configuration values
From: Florian Fainelli @ 2018-04-05 16:00 UTC (permalink / raw)
To: esben.haabendal, Andrew Lunn, open list:ETHERNET PHY LIBRARY,
open list
Cc: Esben Haabendal, Rasmus Villemoes
In-Reply-To: <20180405114424.8519-1-esben.haabendal@gmail.com>
On 04/05/2018 04:44 AM, esben.haabendal@gmail.com wrote:
> From: Esben Haabendal <eha@deif.com>
>
> Add a function for use in PHY driver probe functions, reading current
> autoneg, speed and duplex configuration from BMCR register.
>
> Useful for PHY that supports hardware strapped configuration, enabling
> Linux to respect that configuration (i.e. strapped non-autoneg
> configuration).
>
> Signed-off-by: Esben Haabendal <eha@deif.com>
> Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
> drivers/net/phy/phy_device.c | 41 +++++++++++++++++++++++++++++++++++++++++
> include/linux/phy.h | 1 +
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 74664a6c0cdc..cc52ff2a2344 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1673,6 +1673,47 @@ int genphy_config_init(struct phy_device *phydev)
> }
> EXPORT_SYMBOL(genphy_config_init);
>
> +/**
> + * genphy_read_config - read configuration from PHY
> + * @phydev: target phy_device struct
> + *
> + * Description: Reads MII_BMCR and sets phydev autoneg, speed and duplex
> + * accordingly. For use in driver probe functions, to respect strapped
> + * configuration settings.
> + */
> +int genphy_read_config(struct phy_device *phydev)
This duplicates what already exists, in part at least within
genphy_read_status() can you find a way to use that?
I really wonder how this is going to work though because an user can
decide to force the PHY to have auto-negotiation disabled just like a
MAC could actually attempt to do that while connecting to the PHY...
more comments in patch 2.
--
Florian
^ permalink raw reply
* Re: [PATCH 2/2] net: phy: dp83640: Read strapped configuration settings
From: Florian Fainelli @ 2018-04-05 16:02 UTC (permalink / raw)
To: esben.haabendal, Richard Cochran, Andrew Lunn,
open list:PTP HARDWARE CLOCK SUPPORT, open list
Cc: Esben Haabendal, Rasmus Villemoes
In-Reply-To: <20180405114424.8519-2-esben.haabendal@gmail.com>
On 04/05/2018 04:44 AM, esben.haabendal@gmail.com wrote:
> From: Esben Haabendal <eha@deif.com>
>
> Read configration settings, to allow automatic forced speed/duplex setup
> by hardware strapping.
OK but why? What problem is this solving for you? In general, we do not
really want to preserve too much of what the PHY has been previously
configured with, provided that the PHY driver can re-instate these
configuration values.
I just wonder how this can be robust when you connect this PHY with
auto-negotiation disabled to a peer that expects a set of link
parameters not covered by the default advertisement values? This really
looks like a recipe for disaster when you could just disable
auto-negotiation with ethtool.
>
> Signed-off-by: Esben Haabendal <eha@deif.com>
> Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
> ---
> drivers/net/phy/dp83640.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
> index 654f42d00092..01e21b4998ad 100644
> --- a/drivers/net/phy/dp83640.c
> +++ b/drivers/net/phy/dp83640.c
> @@ -1134,6 +1134,10 @@ static int dp83640_probe(struct phy_device *phydev)
> if (!dp83640)
> goto no_memory;
>
> + err = genphy_read_config(phydev);
> + if (err)
> + goto no_config;
> +
> dp83640->phydev = phydev;
> INIT_DELAYED_WORK(&dp83640->ts_work, rx_timestamp_work);
>
> @@ -1166,6 +1170,7 @@ static int dp83640_probe(struct phy_device *phydev)
>
> no_register:
> clock->chosen = NULL;
> +no_config:
> kfree(dp83640);
> no_memory:
> dp83640_clock_put(clock);
>
--
Florian
^ permalink raw reply
* Re: [PATCH] net: thunderx: rework mac addresses list to u64 array
From: Vadim Lomovtsev @ 2018-04-05 16:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: sgoutham, sunil.kovvuri, rric, linux-arm-kernel, netdev,
linux-kernel, davem, dnelson, gustavo, Vadim Lomovtsev
In-Reply-To: <20180405150748.GA5716@infradead.org>
Hi Christoph,
Thank you for your feedback and time.
On Thu, Apr 05, 2018 at 08:07:48AM -0700, Christoph Hellwig wrote:
> > struct xcast_addr_list {
> > - struct list_head list;
> > int count;
> > + u64 mc[0];
>
> Please use the standard C99 syntax here:
>
> u64 mc[];
Ok, will update.
>
> > + mc_list = kmalloc(sizeof(*mc_list) +
> > + sizeof(u64) * netdev_mc_count(netdev),
> > + GFP_ATOMIC);
>
> kmalloc_array(), please.
In this case it would require two memory allocation calls to kmalloc() for
xcast_addr_list struct and to kmalloc_array() for 'mc' addresses, becasue of
different data types and so two null-ptr checks .. this is what I'd like get rid off.
My idea of this was to keep number of array elements and themselves within the
same memory block/page to reduce number of memory allocation requests, number
of allocated pages/blocks and avoid possible memory fragmentation (however, I believe
the latter is already handled at the mm layer).
WBR,
Vadim
^ permalink raw reply
* Re: marvell switch
From: Andrew Lunn @ 2018-04-05 16:09 UTC (permalink / raw)
To: Ran Shalit; +Cc: netdev
In-Reply-To: <CAJ2oMhKpwfQ3-=syCL1Uy+W0R1CFLW+dDOQpFGw7_bLzdkjfVQ@mail.gmail.com>
> Is there a wiki which explains switch configuration ?
Nope. The whole idea is that they behave like normal linux
interfaces. So there is no need to document them. You already know how
to use them.
> Is it possible to open socket and send/recieve on switch ports (lan0
> for example) ?
Sure. It is as normal interface. Give is an IP address and then do
TCP/IP as usual.
Andrew
^ permalink raw reply
* Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
From: gregkh @ 2018-04-05 16:12 UTC (permalink / raw)
To: Ruxandra Ioana Ciocoi Radulescu
Cc: Andrew Lunn, Laurentiu Tudor, Stuart Yoder, Arnd Bergmann,
Ioana Ciornei, Linux Kernel Mailing List, Razvan Stefanescu,
Roy Pledge, Networking
In-Reply-To: <HE1PR0402MB2700E32234735AC12C18BB8F94BB0@HE1PR0402MB2700.eurprd04.prod.outlook.com>
On Thu, Apr 05, 2018 at 03:35:30PM +0000, Ruxandra Ioana Ciocoi Radulescu wrote:
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > Sent: Thursday, April 5, 2018 6:24 PM
> > To: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > Cc: Stuart Yoder <stuyoder@gmail.com>; Arnd Bergmann <arnd@arndb.de>;
> > Ioana Ciornei <ioana.ciornei@nxp.com>; gregkh
> > <gregkh@linuxfoundation.org>; Linux Kernel Mailing List <linux-
> > kernel@vger.kernel.org>; Ruxandra Ioana Ciocoi Radulescu
> > <ruxandra.radulescu@nxp.com>; Razvan Stefanescu
> > <razvan.stefanescu@nxp.com>; Roy Pledge <roy.pledge@nxp.com>;
> > Networking <netdev@vger.kernel.org>
> > Subject: Re: [PATCH v3 2/4] bus: fsl-mc: add restool userspace support
> >
> > On Thu, Apr 05, 2018 at 02:43:29PM +0000, Laurentiu Tudor wrote:
> > > Hi Andrew,
> > >
> > > On 04/05/2018 03:48 PM, Andrew Lunn wrote:
> > > >>> Hi Laurentiu
> > > >>>
> > > >>> So i can use switchdev without it? I can modprobe the switchdev
> > > >>> driver, all the physical interfaces will appear, and i can use ip addr
> > > >>> add etc. I do not need to use a user space tool at all in order to use
> > > >>> the network functionality?
> > > >>
> > > >> Absolutely!
> > > >
> > > > Great.
> > > >
> > > > Then the easiest way forwards is to simply drop the IOCTL code for the
> > > > moment. Get the basic support for the hardware into the kernel
> > > > first. Then come back later to look at dynamic behaviour which needs
> > > > some form of configuration.
> > >
> > > Hmm, not sure I understand. We already have a fully functional ethernet
> > > driver [1] and a switch driver [2] ...
> >
> > In staging, the tree of crap. You want to get it out of there and into
> > the main tree. But that effort is being side lined by the discussion
> > around this IOCTL call. The best way forward is to to accept Greg is
> > not going to take this patchset at the moment, and move on. As you
> > said, it is not needed for the Ethernet and switchdev driver.
> >
> > What needs to happen before the Ethernet driver can be reviewed for
> > moving out of staging?
>
> Hi Andrew,
>
> We're waiting for the DPIO driver (which we depend on) to be moved
> out of staging first, it's currently under review:
> https://lkml.org/lkml/2018/3/27/1086
That's stalled on my side right now as the merge window is open and I
can't do any new stuff until after 4.17-rc1 is out. So everyone please
be patient a bit...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] net: thunderx: rework mac addresses list to u64 array
From: Christoph Hellwig @ 2018-04-05 16:15 UTC (permalink / raw)
To: Vadim Lomovtsev
Cc: Christoph Hellwig, sgoutham, sunil.kovvuri, rric,
linux-arm-kernel, netdev, linux-kernel, davem, dnelson, gustavo,
Vadim Lomovtsev
In-Reply-To: <20180405160749.GB12703@localhost.localdomain>
On Thu, Apr 05, 2018 at 09:07:49AM -0700, Vadim Lomovtsev wrote:
> >
> > > + mc_list = kmalloc(sizeof(*mc_list) +
> > > + sizeof(u64) * netdev_mc_count(netdev),
> > > + GFP_ATOMIC);
> >
> > kmalloc_array(), please.
>
> In this case it would require two memory allocation calls to kmalloc() for
> xcast_addr_list struct and to kmalloc_array() for 'mc' addresses, becasue of
> different data types and so two null-ptr checks .. this is what I'd like get rid off.
>
> My idea of this was to keep number of array elements and themselves within the
> same memory block/page to reduce number of memory allocation requests, number
> of allocated pages/blocks and avoid possible memory fragmentation (however, I believe
> the latter is already handled at the mm layer).
Indeed, lets keep it as-is.
^ permalink raw reply
* [PATCH] ieee802154: mcr20a: Fix memory leak in mcr20a_probe
From: Gustavo A. R. Silva @ 2018-04-05 16:20 UTC (permalink / raw)
To: Xue Liu, Alexander Aring, Stefan Schmidt
Cc: linux-wpan, netdev, linux-kernel, Gustavo A. R. Silva
Free allocated memory for pdata before return.
Addresses-Coverity-ID: 1466096 ("Resource leak")
Fixes: 8c6ad9cc5157 ("ieee802154: Add NXP MCR20A IEEE 802.15.4 transceiver driver")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ieee802154/mcr20a.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
index 55a22c7..944470d 100644
--- a/drivers/net/ieee802154/mcr20a.c
+++ b/drivers/net/ieee802154/mcr20a.c
@@ -1267,7 +1267,7 @@ mcr20a_probe(struct spi_device *spi)
ret = mcr20a_get_platform_data(spi, pdata);
if (ret < 0) {
dev_crit(&spi->dev, "mcr20a_get_platform_data failed.\n");
- return ret;
+ goto free_pdata;
}
/* init reset gpio */
@@ -1275,7 +1275,7 @@ mcr20a_probe(struct spi_device *spi)
ret = devm_gpio_request_one(&spi->dev, pdata->rst_gpio,
GPIOF_OUT_INIT_HIGH, "reset");
if (ret)
- return ret;
+ goto free_pdata;
}
/* reset mcr20a */
@@ -1291,7 +1291,8 @@ mcr20a_probe(struct spi_device *spi)
hw = ieee802154_alloc_hw(sizeof(*lp), &mcr20a_hw_ops);
if (!hw) {
dev_crit(&spi->dev, "ieee802154_alloc_hw failed\n");
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto free_pdata;
}
/* init mcr20a local data */
@@ -1366,6 +1367,8 @@ mcr20a_probe(struct spi_device *spi)
free_dev:
ieee802154_free_hw(lp->hw);
+free_pdata:
+ kfree(pdata);
return ret;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 bpf-next 0/3] bpf/verifier: subprog/func_call simplifications
From: Edward Cree @ 2018-04-05 16:29 UTC (permalink / raw)
To: Jiong Wang, Alexei Starovoitov; +Cc: Daniel Borkmann, netdev
In-Reply-To: <2ff89131-c6ea-5ddf-156c-c6f6e455fbdd@netronome.com>
On 05/04/18 16:50, Jiong Wang wrote:
> On 03/04/2018 02:08, Alexei Starovoitov wrote:
>> Combining subprog pass with do_check is going into opposite direction
>> of this long term work. Divide and conquer. Combining more things into
>> do_check is the opposite of this programming principle.
>
> Agree. And for the redundant insn traversal issue in check_subprogs that
> Edward trying to fix, I am thinking we could do it by utilizing the
> existing DFS traversal in check_cfg.
>
> The current DFS probably could be improved into an generic instruction
> information collection pass.
<snip>
> And if we want to build basic-block later, we could just call a new add_bb
> (similar as add_subprog) for jump targets etc. (some of those places are
> actually STATE_LIST_MARK_JMPTARGET if we separate STATE_LIST_MARK as
> STATE_LIST_MARK_JMPTARGET and STATE_LIST_MARK_HEURISTIC).
>
> Regards,
> Jiong
>
This is broadly similar to my medium-term plan, except that I would use
the Kahn's-algorithm style tsort rather than the depth-first tsort
algorithm used by current check_cfg.
* chop up prog into functions and bbs, incidentally placing S_L_Ms
* create control flow graph similar to my function call graph
* tsort it to detect loops, similar to how my check_max_stack_depth()
implementation detects recursion.
-Ed
^ permalink raw reply
* Re: [PATCH] qtnfmac: pearl: pcie: fix memory leak in qtnf_fw_work_handler
From: Sergey Matyukevich @ 2018-04-05 16:31 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20180405154949.GA32223@embeddedor.com>
Hello Gustavo,
> In case memory resources for fw were succesfully allocated, release
> them before jumping to fw_load_fail.
>
> Addresses-Coverity-ID: 1466092 ("Resource leak")
> Fixes: c3b2f7ca4186 ("qtnfmac: implement asynchronous firmware loading")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 4 ++++
> 1 file changed, 4 insertions(+)
Thanks for the patch!
Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Regards,
Sergey
^ permalink raw reply
* Re: [PATCH] qtnfmac: pearl: pcie: fix memory leak in qtnf_fw_work_handler
From: Gustavo A. R. Silva @ 2018-04-05 16:33 UTC (permalink / raw)
To: Igor Mitsyanko, Avinash Patil, Sergey Matyukevich, Kalle Valo,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20180405163100.cuaedftds47pxdrn@bars>
Hi Sergey,
On 04/05/2018 11:31 AM, Sergey Matyukevich wrote:
> Hello Gustavo,
>
>> In case memory resources for fw were succesfully allocated, release
>> them before jumping to fw_load_fail.
>>
>> Addresses-Coverity-ID: 1466092 ("Resource leak")
>> Fixes: c3b2f7ca4186 ("qtnfmac: implement asynchronous firmware loading")
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> ---
>> drivers/net/wireless/quantenna/qtnfmac/pearl/pcie.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>
> Thanks for the patch!
>
Glad to help. :)
> Reviewed-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
>
Thanks
--
Gustavo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox