[PATCH 0/2] perf bpf: Fix relocation error

[PATCH 0/2] perf bpf: Fix relocation error

[Wang Nan]

Alexei notices me about a bug in llvm [1]. Because of this bug,
even a normal BPF program can generate incorrect (or redundant)
relocation information.

Patch 1 adds a new test case about it (use an buggy BPF script, should
fail even LLVM's bug is fixed). Since it is the first test case expected
to be fail, test framework is slightly adjusted.

Patch 2 adds the checker.

[1] https://llvm.org/bugs/show_bug.cgi?id=26243

Wang Nan (2):
  perf test: Add libbpf relocation checker
  perf bpf: Check relocation target section

 tools/lib/bpf/libbpf.c                        | 34 +++++++++++-------
 tools/perf/Makefile.perf                      |  2 +-
 tools/perf/tests/.gitignore                   |  1 +
 tools/perf/tests/Build                        |  9 ++++-
 tools/perf/tests/bpf-script-test-relocation.c | 50 +++++++++++++++++++++++++++
 tools/perf/tests/bpf.c                        | 26 +++++++++++---
 tools/perf/tests/llvm.c                       | 17 ++++++---
 tools/perf/tests/llvm.h                       |  5 ++-
 8 files changed, 120 insertions(+), 24 deletions(-)
 create mode 100644 tools/perf/tests/bpf-script-test-relocation.c

Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Li Zefan <lizefan@huawei.com>              
Cc: pi3orama@163.com
-- 
1.8.3.4

[PATCH 1/2] perf test: Add libbpf relocation checker

[Wang Nan]

There's a bug in LLVM that it can generate unneeded relocation
information. See [1] and [2]. Libbpf should check the target section
of a relocation symbol.

This patch adds a testcase which reference a global variable (BPF
doesn't support global variable). Before fixing libbpf, the new test
case can be loaded into kernel, the global variable acts like the first
map. It is incorrect.

Result:
 # ~/perf test BPF
 37: Test BPF filter                                          :
 37.1: Test basic BPF filtering                               : Ok
 37.2: Test BPF prologue generation                           : Ok
 37.3: Test BPF relocation checker                            : FAILED!

 # ~/perf test -v BPF
 ...
 libbpf: loading object '[bpf_relocation_test]' from buffer
 libbpf: section .strtab, size 126, link 0, flags 0, type=3
 libbpf: section .text, size 0, link 0, flags 6, type=1
 libbpf: section .data, size 0, link 0, flags 3, type=1
 libbpf: section .bss, size 0, link 0, flags 3, type=8
 libbpf: section func=sys_write, size 104, link 0, flags 6, type=1
 libbpf: found program func=sys_write
 libbpf: section .relfunc=sys_write, size 16, link 10, flags 0, type=9
 libbpf: section maps, size 16, link 0, flags 3, type=1
 libbpf: maps in [bpf_relocation_test]: 16 bytes
 libbpf: section license, size 4, link 0, flags 3, type=1
 libbpf: license of [bpf_relocation_test] is GPL
 libbpf: section version, size 4, link 0, flags 3, type=1
 libbpf: kernel version of [bpf_relocation_test] is 40400
 libbpf: section .symtab, size 144, link 1, flags 0, type=2
 libbpf: map 0 is "my_table"
 libbpf: collecting relocating info for: 'func=sys_write'
 libbpf: relocation: insn_idx=7
 Success unexpectedly: libbpf error when dealing with relocation
 test child finished with -1
 ---- end ----
 Test BPF filter subtest 2: FAILED!

[1] https://llvm.org/bugs/show_bug.cgi?id=26243
[2] https://patchwork.ozlabs.org/patch/571385/

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Li Zefan <lizefan@huawei.com>
Cc: pi3orama@163.com
---
 tools/perf/Makefile.perf                      |  2 +-
 tools/perf/tests/.gitignore                   |  1 +
 tools/perf/tests/Build                        |  9 ++++-
 tools/perf/tests/bpf-script-test-relocation.c | 50 +++++++++++++++++++++++++++
 tools/perf/tests/bpf.c                        | 26 +++++++++++---
 tools/perf/tests/llvm.c                       | 17 ++++++---
 tools/perf/tests/llvm.h                       |  5 ++-
 7 files changed, 98 insertions(+), 12 deletions(-)
 create mode 100644 tools/perf/tests/bpf-script-test-relocation.c

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 5d34815..97ce869 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -618,7 +618,7 @@ clean: $(LIBTRACEEVENT)-clean $(LIBAPI)-clean $(LIBBPF)-clean $(LIBSUBCMD)-clean
 	$(call QUIET_CLEAN, core-progs) $(RM) $(ALL_PROGRAMS) perf perf-read-vdso32 perf-read-vdsox32
 	$(call QUIET_CLEAN, core-gen)   $(RM)  *.spec *.pyc *.pyo */*.pyc */*.pyo $(OUTPUT)common-cmds.h TAGS tags cscope* $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)FEATURE-DUMP $(OUTPUT)util/*-bison* $(OUTPUT)util/*-flex* \
 		$(OUTPUT)util/intel-pt-decoder/inat-tables.c $(OUTPUT)fixdep \
-		$(OUTPUT)tests/llvm-src-{base,kbuild,prologue}.c
+		$(OUTPUT)tests/llvm-src-{base,kbuild,prologue,relocation}.c
 	$(QUIET_SUBDIR0)Documentation $(QUIET_SUBDIR1) clean
 	$(python-clean)
 
diff --git a/tools/perf/tests/.gitignore b/tools/perf/tests/.gitignore
index bf016c4..8cc30e7 100644
--- a/tools/perf/tests/.gitignore
+++ b/tools/perf/tests/.gitignore
@@ -1,3 +1,4 @@
 llvm-src-base.c
 llvm-src-kbuild.c
 llvm-src-prologue.c
+llvm-src-relocation.c
diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
index 614899b..1ba628e 100644
--- a/tools/perf/tests/Build
+++ b/tools/perf/tests/Build
@@ -31,7 +31,7 @@ perf-y += sample-parsing.o
 perf-y += parse-no-sample-id-all.o
 perf-y += kmod-path.o
 perf-y += thread-map.o
-perf-y += llvm.o llvm-src-base.o llvm-src-kbuild.o llvm-src-prologue.o
+perf-y += llvm.o llvm-src-base.o llvm-src-kbuild.o llvm-src-prologue.o llvm-src-relocation.o
 perf-y += bpf.o
 perf-y += topology.o
 perf-y += cpumap.o
@@ -59,6 +59,13 @@ $(OUTPUT)tests/llvm-src-prologue.c: tests/bpf-script-test-prologue.c tests/Build
 	$(Q)sed -e 's/"/\\"/g' -e 's/\(.*\)/"\1\\n"/g' $< >> $@
 	$(Q)echo ';' >> $@
 
+$(OUTPUT)tests/llvm-src-relocation.c: tests/bpf-script-test-relocation.c tests/Build
+	$(call rule_mkdir)
+	$(Q)echo '#include <tests/llvm.h>' > $@
+	$(Q)echo 'const char test_llvm__bpf_test_relocation[] =' >> $@
+	$(Q)sed -e 's/"/\\"/g' -e 's/\(.*\)/"\1\\n"/g' $< >> $@
+	$(Q)echo ';' >> $@
+
 ifeq ($(ARCH),$(filter $(ARCH),x86 arm arm64))
 perf-$(CONFIG_DWARF_UNWIND) += dwarf-unwind.o
 endif
diff --git a/tools/perf/tests/bpf-script-test-relocation.c b/tools/perf/tests/bpf-script-test-relocation.c
new file mode 100644
index 0000000..93af774
--- /dev/null
+++ b/tools/perf/tests/bpf-script-test-relocation.c
@@ -0,0 +1,50 @@
+/*
+ * bpf-script-test-relocation.c
+ * Test BPF loader checking relocation
+ */
+#ifndef LINUX_VERSION_CODE
+# error Need LINUX_VERSION_CODE
+# error Example: for 4.2 kernel, put 'clang-opt="-DLINUX_VERSION_CODE=0x40200" into llvm section of ~/.perfconfig'
+#endif
+#define BPF_ANY 0
+#define BPF_MAP_TYPE_ARRAY 2
+#define BPF_FUNC_map_lookup_elem 1
+#define BPF_FUNC_map_update_elem 2
+
+static void *(*bpf_map_lookup_elem)(void *map, void *key) =
+	(void *) BPF_FUNC_map_lookup_elem;
+static void *(*bpf_map_update_elem)(void *map, void *key, void *value, int flags) =
+	(void *) BPF_FUNC_map_update_elem;
+
+struct bpf_map_def {
+	unsigned int type;
+	unsigned int key_size;
+	unsigned int value_size;
+	unsigned int max_entries;
+};
+
+#define SEC(NAME) __attribute__((section(NAME), used))
+struct bpf_map_def SEC("maps") my_table = {
+	.type = BPF_MAP_TYPE_ARRAY,
+	.key_size = sizeof(int),
+	.value_size = sizeof(int),
+	.max_entries = 1,
+};
+
+int this_is_a_global_val;
+
+SEC("func=sys_write")
+int bpf_func__sys_write(void *ctx)
+{
+	int key = 0;
+	int value = 0;
+
+	/*
+	 * Incorrect relocation. Should not allow this program be
+	 * loaded into kernel.
+	 */
+	bpf_map_update_elem(&this_is_a_global_val, &key, &value, 0);
+	return 0;
+}
+char _license[] SEC("license") = "GPL";
+int _version SEC("version") = LINUX_VERSION_CODE;
diff --git a/tools/perf/tests/bpf.c b/tools/perf/tests/bpf.c
index 33689a0..952ca99 100644
--- a/tools/perf/tests/bpf.c
+++ b/tools/perf/tests/bpf.c
@@ -71,6 +71,15 @@ static struct {
 		(NR_ITERS + 1) / 4,
 	},
 #endif
+	{
+		LLVM_TESTCASE_BPF_RELOCATION,
+		"Test BPF relocation checker",
+		"[bpf_relocation_test]",
+		"fix 'perf test LLVM' first",
+		"libbpf error when dealing with relocation",
+		NULL,
+		0,
+	},
 };
 
 static int do_test(struct bpf_object *obj, int (*func)(void),
@@ -190,7 +199,7 @@ static int __test__bpf(int idx)
 
 	ret = test_llvm__fetch_bpf_obj(&obj_buf, &obj_buf_sz,
 				       bpf_testcase_table[idx].prog_id,
-				       true);
+				       true, NULL);
 	if (ret != TEST_OK || !obj_buf || !obj_buf_sz) {
 		pr_debug("Unable to get BPF object, %s\n",
 			 bpf_testcase_table[idx].msg_compile_fail);
@@ -202,14 +211,21 @@ static int __test__bpf(int idx)
 
 	obj = prepare_bpf(obj_buf, obj_buf_sz,
 			  bpf_testcase_table[idx].name);
-	if (!obj) {
+	if ((!!bpf_testcase_table[idx].target_func) != (!!obj)) {
+		if (!obj)
+			pr_debug("Fail to load BPF object: %s\n",
+				 bpf_testcase_table[idx].msg_load_fail);
+		else
+			pr_debug("Success unexpectedly: %s\n",
+				 bpf_testcase_table[idx].msg_load_fail);
 		ret = TEST_FAIL;
 		goto out;
 	}
 
-	ret = do_test(obj,
-		      bpf_testcase_table[idx].target_func,
-		      bpf_testcase_table[idx].expect_result);
+	if (obj)
+		ret = do_test(obj,
+			      bpf_testcase_table[idx].target_func,
+			      bpf_testcase_table[idx].expect_result);
 out:
 	bpf__clear();
 	return ret;
diff --git a/tools/perf/tests/llvm.c b/tools/perf/tests/llvm.c
index 06f45c1..70edcdf 100644
--- a/tools/perf/tests/llvm.c
+++ b/tools/perf/tests/llvm.c
@@ -35,6 +35,7 @@ static int test__bpf_parsing(void *obj_buf __maybe_unused,
 static struct {
 	const char *source;
 	const char *desc;
+	bool should_load_fail;
 } bpf_source_table[__LLVM_TESTCASE_MAX] = {
 	[LLVM_TESTCASE_BASE] = {
 		.source = test_llvm__bpf_base_prog,
@@ -48,14 +49,19 @@ static struct {
 		.source = test_llvm__bpf_test_prologue_prog,
 		.desc = "Compile source for BPF prologue generation test",
 	},
+	[LLVM_TESTCASE_BPF_RELOCATION] = {
+		.source = test_llvm__bpf_test_relocation,
+		.desc = "Compile source for BPF relocation test",
+		.should_load_fail = true,
+	},
 };
 
-
 int
 test_llvm__fetch_bpf_obj(void **p_obj_buf,
 			 size_t *p_obj_buf_sz,
 			 enum test_llvm__testcase idx,
-			 bool force)
+			 bool force,
+			 bool *should_load_fail)
 {
 	const char *source;
 	const char *desc;
@@ -68,6 +74,8 @@ test_llvm__fetch_bpf_obj(void **p_obj_buf,
 
 	source = bpf_source_table[idx].source;
 	desc = bpf_source_table[idx].desc;
+	if (should_load_fail)
+		*should_load_fail = bpf_source_table[idx].should_load_fail;
 
 	perf_config(perf_config_cb, NULL);
 
@@ -136,14 +144,15 @@ int test__llvm(int subtest)
 	int ret;
 	void *obj_buf = NULL;
 	size_t obj_buf_sz = 0;
+	bool should_load_fail = false;
 
 	if ((subtest < 0) || (subtest >= __LLVM_TESTCASE_MAX))
 		return TEST_FAIL;
 
 	ret = test_llvm__fetch_bpf_obj(&obj_buf, &obj_buf_sz,
-				       subtest, false);
+				       subtest, false, &should_load_fail);
 
-	if (ret == TEST_OK) {
+	if (ret == TEST_OK && !should_load_fail) {
 		ret = test__bpf_parsing(obj_buf, obj_buf_sz);
 		if (ret != TEST_OK) {
 			pr_debug("Failed to parse test case '%s'\n",
diff --git a/tools/perf/tests/llvm.h b/tools/perf/tests/llvm.h
index 5150b4d..0eaa604 100644
--- a/tools/perf/tests/llvm.h
+++ b/tools/perf/tests/llvm.h
@@ -7,14 +7,17 @@
 extern const char test_llvm__bpf_base_prog[];
 extern const char test_llvm__bpf_test_kbuild_prog[];
 extern const char test_llvm__bpf_test_prologue_prog[];
+extern const char test_llvm__bpf_test_relocation[];
 
 enum test_llvm__testcase {
 	LLVM_TESTCASE_BASE,
 	LLVM_TESTCASE_KBUILD,
 	LLVM_TESTCASE_BPF_PROLOGUE,
+	LLVM_TESTCASE_BPF_RELOCATION,
 	__LLVM_TESTCASE_MAX,
 };
 
 int test_llvm__fetch_bpf_obj(void **p_obj_buf, size_t *p_obj_buf_sz,
-			     enum test_llvm__testcase index, bool force);
+			     enum test_llvm__testcase index, bool force,
+			     bool *should_load_fail);
 #endif
-- 
1.8.3.4

[PATCH 2/2] perf bpf: Check relocation target section

[Wang Nan]

Libbpf should check target section before doing relocation to ensure
the relocation is correct. If not, a bug in LLVM causes error. See [1].
Also, if an incorrect BPF script uses both global variable and
map, global variable whould be treated as map and be relocated
without error.

This patch saves id of map section into obj->efile and compare
target section of a relocation symbol against it during relocation.

Previous patch introduces a test case about this problem.
After this patch:

 # ~/perf test BPF
 37: Test BPF filter                                          :
 37.1: Test basic BPF filtering                               : Ok
 37.2: Test BPF prologue generation                           : Ok
 37.3: Test BPF relocation checker                            : Ok

 # perf test -v BPF
 ...
 37.3: Test BPF relocation checker                            :
 ...
 libbpf: loading object '[bpf_relocation_test]' from buffer
 libbpf: section .strtab, size 126, link 0, flags 0, type=3
 libbpf: section .text, size 0, link 0, flags 6, type=1
 libbpf: section .data, size 0, link 0, flags 3, type=1
 libbpf: section .bss, size 0, link 0, flags 3, type=8
 libbpf: section func=sys_write, size 104, link 0, flags 6, type=1
 libbpf: found program func=sys_write
 libbpf: section .relfunc=sys_write, size 16, link 10, flags 0, type=9
 libbpf: section maps, size 16, link 0, flags 3, type=1
 libbpf: maps in [bpf_relocation_test]: 16 bytes
 libbpf: section license, size 4, link 0, flags 3, type=1
 libbpf: license of [bpf_relocation_test] is GPL
 libbpf: section version, size 4, link 0, flags 3, type=1
 libbpf: kernel version of [bpf_relocation_test] is 40400
 libbpf: section .symtab, size 144, link 1, flags 0, type=2
 libbpf: map 0 is "my_table"
 libbpf: collecting relocating info for: 'func=sys_write'
 libbpf: Program 'func=sys_write' contains non-map related relo data pointing to section 65522
 bpf: failed to load buffer
 Compile BPF program failed.
 test child finished with 0
 ---- end ----
 Test BPF filter subtest 2: Ok

[1] https://llvm.org/bugs/show_bug.cgi?id=26243

Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Li Zefan <lizefan@huawei.com>
Cc: pi3orama@163.com
---
 tools/lib/bpf/libbpf.c | 34 ++++++++++++++++++++++------------
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 8334a5a..8fa781f 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -201,6 +201,7 @@ struct bpf_object {
 			Elf_Data *data;
 		} *reloc;
 		int nr_reloc;
+		int maps_shndx;
 	} efile;
 	/*
 	 * All loaded bpf_object is linked in a list, which is
@@ -350,6 +351,7 @@ static struct bpf_object *bpf_object__new(const char *path,
 	 */
 	obj->efile.obj_buf = obj_buf;
 	obj->efile.obj_buf_sz = obj_buf_sz;
+	obj->efile.maps_shndx = -1;
 
 	obj->loaded = false;
 
@@ -529,12 +531,12 @@ bpf_object__init_maps(struct bpf_object *obj, void *data,
 }
 
 static int
-bpf_object__init_maps_name(struct bpf_object *obj, int maps_shndx)
+bpf_object__init_maps_name(struct bpf_object *obj)
 {
 	int i;
 	Elf_Data *symbols = obj->efile.symbols;
 
-	if (!symbols || maps_shndx < 0)
+	if (!symbols || obj->efile.maps_shndx < 0)
 		return -EINVAL;
 
 	for (i = 0; i < symbols->d_size / sizeof(GElf_Sym); i++) {
@@ -544,7 +546,7 @@ bpf_object__init_maps_name(struct bpf_object *obj, int maps_shndx)
 
 		if (!gelf_getsym(symbols, i, &sym))
 			continue;
-		if (sym.st_shndx != maps_shndx)
+		if (sym.st_shndx != obj->efile.maps_shndx)
 			continue;
 
 		map_name = elf_strptr(obj->efile.elf,
@@ -572,7 +574,7 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
 	Elf *elf = obj->efile.elf;
 	GElf_Ehdr *ep = &obj->efile.ehdr;
 	Elf_Scn *scn = NULL;
-	int idx = 0, err = 0, maps_shndx = -1;
+	int idx = 0, err = 0;
 
 	/* Elf is corrupted/truncated, avoid calling elf_strptr. */
 	if (!elf_rawdata(elf_getscn(elf, ep->e_shstrndx), NULL)) {
@@ -625,7 +627,7 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
 		else if (strcmp(name, "maps") == 0) {
 			err = bpf_object__init_maps(obj, data->d_buf,
 						    data->d_size);
-			maps_shndx = idx;
+			obj->efile.maps_shndx = idx;
 		} else if (sh.sh_type == SHT_SYMTAB) {
 			if (obj->efile.symbols) {
 				pr_warning("bpf: multiple SYMTAB in %s\n",
@@ -674,8 +676,8 @@ static int bpf_object__elf_collect(struct bpf_object *obj)
 		pr_warning("Corrupted ELF file: index of strtab invalid\n");
 		return LIBBPF_ERRNO__FORMAT;
 	}
-	if (maps_shndx >= 0)
-		err = bpf_object__init_maps_name(obj, maps_shndx);
+	if (obj->efile.maps_shndx >= 0)
+		err = bpf_object__init_maps_name(obj);
 out:
 	return err;
 }
@@ -697,7 +699,8 @@ bpf_object__find_prog_by_idx(struct bpf_object *obj, int idx)
 static int
 bpf_program__collect_reloc(struct bpf_program *prog,
 			   size_t nr_maps, GElf_Shdr *shdr,
-			   Elf_Data *data, Elf_Data *symbols)
+			   Elf_Data *data, Elf_Data *symbols,
+			   int maps_shndx)
 {
 	int i, nrels;
 
@@ -724,9 +727,6 @@ bpf_program__collect_reloc(struct bpf_program *prog,
 			return -LIBBPF_ERRNO__FORMAT;
 		}
 
-		insn_idx = rel.r_offset / sizeof(struct bpf_insn);
-		pr_debug("relocation: insn_idx=%u\n", insn_idx);
-
 		if (!gelf_getsym(symbols,
 				 GELF_R_SYM(rel.r_info),
 				 &sym)) {
@@ -735,6 +735,15 @@ bpf_program__collect_reloc(struct bpf_program *prog,
 			return -LIBBPF_ERRNO__FORMAT;
 		}
 
+		if (sym.st_shndx != maps_shndx) {
+			pr_warning("Program '%s' contains non-map related relo data pointing to section %u\n",
+				   prog->section_name, sym.st_shndx);
+			return -LIBBPF_ERRNO__RELOC; 
+		}
+
+		insn_idx = rel.r_offset / sizeof(struct bpf_insn);
+		pr_debug("relocation: insn_idx=%u\n", insn_idx);
+
 		if (insns[insn_idx].code != (BPF_LD | BPF_IMM | BPF_DW)) {
 			pr_warning("bpf: relocation: invalid relo for insns[%d].code 0x%x\n",
 				   insn_idx, insns[insn_idx].code);
@@ -863,7 +872,8 @@ static int bpf_object__collect_reloc(struct bpf_object *obj)
 
 		err = bpf_program__collect_reloc(prog, nr_maps,
 						 shdr, data,
-						 obj->efile.symbols);
+						 obj->efile.symbols,
+						 obj->efile.maps_shndx);
 		if (err)
 			return err;
 	}
-- 
1.8.3.4

Re: [PATCH 1/2] perf test: Add libbpf relocation checker

[Arnaldo Carvalho de Melo]

Em Fri, Jan 22, 2016 at 09:27:20AM +0000, Wang Nan escreveu:
> There's a bug in LLVM that it can generate unneeded relocation
> information. See [1] and [2]. Libbpf should check the target section
> of a relocation symbol.
> 
> This patch adds a testcase which reference a global variable (BPF
> doesn't support global variable). Before fixing libbpf, the new test
> case can be loaded into kernel, the global variable acts like the first
> map. It is incorrect.
> 
> Result:
>  # ~/perf test BPF
>  37: Test BPF filter                                          :
>  37.1: Test basic BPF filtering                               : Ok
>  37.2: Test BPF prologue generation                           : Ok
>  37.3: Test BPF relocation checker                            : FAILED!

So I just got a new notebook, a t450s (heya, will be able to test Intel
PT, etc) and installed fedora 23 on it, cool, there is clang/llvm in it!
And furthermore:

[root@jouet ~]# clang --version
clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix
[root@jouet ~]# 

Seems to be the one we need!

But...

[root@jouet ~]# perf test bpf
37: Test BPF filter                                          :
37.1: Test basic BPF filtering                               : Skip
37.2: Test BPF prologue generation                           : Skip
[root@jouet ~]# 

oh well...

>From 'perf test -v bpf':

' | $CLANG_EXEC -D__KERNEL__ -D__NR_CPUS__=$NR_CPUS -DLINUX_VERSION_CODE=$LINUX_VERSION_CODE $CLANG_OPTIONS $KERNEL_INC_OPTIONS -Wno-unused-value -Wno-pointer-sign -working-directory $WORKING_DIR -c "$CLANG_SOURCE" -target bpf -O2 -o -
error: unable to create target: 'No available targets are compatible with this triple, see -version for the available targets.'

----

And after googling 'list clang supported target'

[root@jouet ~]# llc --version
LLVM (http://llvm.org/):
  LLVM version 3.7.0
  Optimized build.
  Built Dec  4 2015 (15:49:18).
  Default target: x86_64-redhat-linux-gnu
  Host CPU: broadwell

  Registered Targets:
    aarch64    - AArch64 (little endian)
    aarch64_be - AArch64 (big endian)
    amdgcn     - AMD GCN GPUs
    arm        - ARM
    arm64      - ARM64 (little endian)
    armeb      - ARM (big endian)
    cpp        - C++ backend
    nvptx      - NVIDIA PTX 32-bit
    nvptx64    - NVIDIA PTX 64-bit
    ppc32      - PowerPC 32
    ppc64      - PowerPC 64
    ppc64le    - PowerPC 64 LE
    r600       - AMD GPUs HD2XXX-HD6XXX
    systemz    - SystemZ
    thumb      - Thumb
    thumbeb    - Thumb (big endian)
    x86        - 32-bit X86: Pentium-Pro and above
    x86-64     - 64-bit X86: EM64T and AMD64
[root@jouet ~]# 

Oops, no bpf, so the good thing is that if we uninstall clang and try that test again:

[root@jouet ~]# dnf remove clang llvm
Dependencies resolved.
==============================================================
 Package              Arch    Version       Repository   Size
==============================================================
Removing:
 clang                x86_64  3.7.0-3.fc23  @updates     45 M
 clang-libs           x86_64  3.7.0-3.fc23  @updates     14 M
 gcc-c++              x86_64  5.3.1-2.fc23  @updates     24 M
 libstdc++-devel      x86_64  5.3.1-2.fc23  @updates    9.5 M
 llvm                 x86_64  3.7.0-3.fc23  @updates    4.9 M

Transaction Summary
==============================================================
Remove  5 Packages


When I try it again I get nice instructions on how to install it!

[root@jouet ~]# perf test bpf
37: Test BPF filter                                          :
37.1: Test basic BPF filtering                               : Skip
37.2: Test BPF prologue generation                           : Skip
[root@jouet ~]# perf test -v bpf
37: Test BPF filter                                          :
37.1: Test basic BPF filtering                               :
--- start ---
test child forked, pid 30062
ERROR:	unable to find clang.
Hint:	Try to install latest clang/llvm to support BPF. Check your $PATH
     	and 'clang-path' option in [llvm] section of ~/.perfconfig.
     	LLVM 3.7 or newer is required. Which can be found from http://llvm.org
     	You may want to try git trunk:
     		git clone http://llvm.org/git/llvm.git
     		     and
     		git clone http://llvm.org/git/clang.git

     	Or fetch the latest clang/llvm 3.7 from pre-built llvm packages for
     	debian/ubuntu:
     		http://llvm.org/apt

     	If you are using old version of clang, change 'clang-bpf-cmd-template'
     	option in [llvm] section of ~/.perfconfig to:

     	  "$CLANG_EXEC $CLANG_OPTIONS $KERNEL_INC_OPTIONS \
     	     -working-directory $WORKING_DIR -c $CLANG_SOURCE \
     	     -emit-llvm -o - | /path/to/llc -march=bpf -filetype=obj -o -"
     	(Replace /path/to/llc with path to your llc)

Failed to compile test case: 'Basic BPF llvm compiling test'
Unable to get BPF object, fix 'perf test LLVM' first
test child finished with -2
---- end ----
Test BPF filter subtest 0: Skip
37.2: Test BPF prologue generation                           :
--- force skipped ---
Test BPF filter subtest 1: Skip
[root@jouet ~]# 

Lets try it...

- Arnaldo

Re: [PATCH 1/2] perf test: Add libbpf relocation checker

[Alexei Starovoitov]

On Fri, Jan 22, 2016 at 12:40:50PM -0300, Arnaldo Carvalho de Melo wrote:
> [root@jouet ~]# llc --version
> LLVM (http://llvm.org/):
>   LLVM version 3.7.0
>   Optimized build.
>   Built Dec  4 2015 (15:49:18).
>   Default target: x86_64-redhat-linux-gnu
>   Host CPU: broadwell
> 
>   Registered Targets:
>     aarch64    - AArch64 (little endian)
>     aarch64_be - AArch64 (big endian)
>     amdgcn     - AMD GCN GPUs
>     arm        - ARM
>     arm64      - ARM64 (little endian)
>     armeb      - ARM (big endian)
>     cpp        - C++ backend
>     nvptx      - NVIDIA PTX 32-bit
>     nvptx64    - NVIDIA PTX 64-bit
>     ppc32      - PowerPC 32
>     ppc64      - PowerPC 64
>     ppc64le    - PowerPC 64 LE
>     r600       - AMD GPUs HD2XXX-HD6XXX
>     systemz    - SystemZ
>     thumb      - Thumb
>     thumbeb    - Thumb (big endian)
>     x86        - 32-bit X86: Pentium-Pro and above
>     x86-64     - 64-bit X86: EM64T and AMD64
> [root@jouet ~]# 

ouch, so fedorra enabled all sorts of backends, but disabled BPF?!
Can somebody talk to redhat packaging folks?
clang/llvm enables BPF backend by default.

Re: [PATCH 2/2] perf bpf: Check relocation target section

[Alexei Starovoitov]

On Fri, Jan 22, 2016 at 09:27:21AM +0000, Wang Nan wrote:
> Libbpf should check target section before doing relocation to ensure
> the relocation is correct. If not, a bug in LLVM causes error. See [1].
> Also, if an incorrect BPF script uses both global variable and
> map, global variable whould be treated as map and be relocated
> without error.
> 
> This patch saves id of map section into obj->efile and compare
> target section of a relocation symbol against it during relocation.
...
> [1] https://llvm.org/bugs/show_bug.cgi?id=26243
...
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
>  
> +		if (sym.st_shndx != maps_shndx) {
> +			pr_warning("Program '%s' contains non-map related relo data pointing to section %u\n",
> +				   prog->section_name, sym.st_shndx);
> +			return -LIBBPF_ERRNO__RELOC; 
> +		}

May be 'pr_err' instead of 'pr_warning', since such program will fail
to load by kernel anyway. Looks good otherwise.
Acked-by: Alexei Starovoitov <ast@kernel.org>

clang --target=bpf missing on f23 was: Re: [PATCH 1/2] perf test: Add libbpf relocation checker

[Arnaldo Carvalho de Melo]

Em Fri, Jan 22, 2016 at 09:07:50AM -0800, Alexei Starovoitov escreveu:
> On Fri, Jan 22, 2016 at 12:40:50PM -0300, Arnaldo Carvalho de Melo wrote:
> > [root@jouet ~]# llc --version
> > LLVM (http://llvm.org/):
> >   LLVM version 3.7.0
> >   Optimized build.
> >   Built Dec  4 2015 (15:49:18).
> >   Default target: x86_64-redhat-linux-gnu
> >   Host CPU: broadwell
> > 
> >   Registered Targets:
> >     aarch64    - AArch64 (little endian)
> >     aarch64_be - AArch64 (big endian)
> >     amdgcn     - AMD GCN GPUs
> >     arm        - ARM
> >     arm64      - ARM64 (little endian)
> >     armeb      - ARM (big endian)
> >     cpp        - C++ backend
> >     nvptx      - NVIDIA PTX 32-bit
> >     nvptx64    - NVIDIA PTX 64-bit
> >     ppc32      - PowerPC 32
> >     ppc64      - PowerPC 64
> >     ppc64le    - PowerPC 64 LE
> >     r600       - AMD GPUs HD2XXX-HD6XXX
> >     systemz    - SystemZ
> >     thumb      - Thumb
> >     thumbeb    - Thumb (big endian)
> >     x86        - 32-bit X86: Pentium-Pro and above
> >     x86-64     - 64-bit X86: EM64T and AMD64
> > [root@jouet ~]# 
> 
> ouch, so fedora enabled all sorts of backends, but disabled BPF?!
> Can somebody talk to redhat packaging folks?
> clang/llvm enables BPF backend by default.

Adding Adam Jackson and Dave Airlie, that last updated llvm.

Hi Adam, Dave,

	the 'bpf' target for clang is being used together with perf to
build scriptlets into object code that then gets uploaded to the kernel
via sys_bpf(), was the decision not to include 'bpf' just an accident?

BTW, this is on a recently installed Fedora 23 machine.

- Arnaldo

[acme@jouet linux]$ rpm -q --changelog llvm-libs | grep -v ^$ | head -20
* Thu Dec 03 2015 Stephan Bergmann <sbergman@redhat.com> 3.7.0-3
- Resolves: rhbz#1282645 add GCC abi_tag support
* Thu Oct 29 2015 Adam Jackson <ajax@redhat.com> 3.7.0-2
- Drop -fno-devirtualize
- Link with -static-libstdc++ to work around bundled libstdc++ in Steam
* Wed Sep 16 2015 Dave Airlie <airlied@redhat.com> 3.7.0-1
- llvm 3.7.0
* Wed Jul 22 2015 Adam Jackson <ajax@redhat.com> 3.6.2-1
- llvm 3.6.2
* Wed Jun 17 2015 Dave Airlie <airlied@redhat.com> 3.6.1-1
- llvm 3.6.1
* Fri May 29 2015 Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> - 3.6.0-2
- Also require gcc-c++ at runtime (#1021645)
* Thu Apr 09 2015 Adam Jackson <ajax@redhat.com> 3.6.0-1
- llvm 3.6.0
* Wed Feb 18 2015 Jonathan Wakely <jwakely@redhat.com> - 3.5.0-11
- Add patch for http://llvm.org/bugs/show_bug.cgi?id=22625
* Wed Feb 18 2015 Richard W.M. Jones <rjones@redhat.com> - 3.5.0-10
- Bump release and rebuild.
* Tue Feb 17 2015 Peter Robinson <pbrobinson@fedoraproject.org> 3.5.0-9
[acme@jouet linux]$

Re: clang --target=bpf missing on f23 was: Re: [PATCH 1/2] perf test: Add libbpf relocation checker

[Adam Jackson]

On Fri, 2016-01-22 at 14:22 -0300, Arnaldo Carvalho de Melo wrote:

> 	the 'bpf' target for clang is being used together with perf to
> build scriptlets into object code that then gets uploaded to the kernel
> via sys_bpf(), was the decision not to include 'bpf' just an accident?

I wouldn't call it a "decision", that would imply intent. The main
reason I explicitly list targets for llvm is to limit the CPU backends
to arches Fedora actually runs on (which itself is because I really
only care about llvmpipe, and am only touching llvm because it's in my
way). Had no idea there was a bpf backend, so never thought to enable
it.

llvm-3.7.0-4.fc2{3,4} are building now with the bpf backend enabled,
I'll create an update for F23 when it's built.

- ajax

Re: clang --target=bpf missing on f23 was: Re: [PATCH 1/2] perf test: Add libbpf relocation checker

[Alexei Starovoitov]

On Fri, Jan 22, 2016 at 12:35:42PM -0500, Adam Jackson wrote:
> On Fri, 2016-01-22 at 14:22 -0300, Arnaldo Carvalho de Melo wrote:
> 
> > 	the 'bpf' target for clang is being used together with perf to
> > build scriptlets into object code that then gets uploaded to the kernel
> > via sys_bpf(), was the decision not to include 'bpf' just an accident?
> 
> I wouldn't call it a "decision", that would imply intent. The main
> reason I explicitly list targets for llvm is to limit the CPU backends
> to arches Fedora actually runs on (which itself is because I really
> only care about llvmpipe, and am only touching llvm because it's in my
> way). Had no idea there was a bpf backend, so never thought to enable
> it.
> 
> llvm-3.7.0-4.fc2{3,4} are building now with the bpf backend enabled,
> I'll create an update for F23 when it's built.

thanks.
if you want to reduce the size of binaries, you can probably disable
nvptx/amdgcn/r600, since I doubt fedora ships with appropriate sdks
that can take advantage of that.

Re: clang --target=bpf missing on f23 was: Re: [PATCH 1/2] perf test: Add libbpf relocation checker

[Daniel Borkmann]

On 01/22/2016 06:35 PM, Adam Jackson wrote:
> On Fri, 2016-01-22 at 14:22 -0300, Arnaldo Carvalho de Melo wrote:
>
>> 	the 'bpf' target for clang is being used together with perf to
>> build scriptlets into object code that then gets uploaded to the kernel
>> via sys_bpf(), was the decision not to include 'bpf' just an accident?
>
> I wouldn't call it a "decision", that would imply intent. The main
> reason I explicitly list targets for llvm is to limit the CPU backends
> to arches Fedora actually runs on (which itself is because I really
> only care about llvmpipe, and am only touching llvm because it's in my
> way). Had no idea there was a bpf backend, so never thought to enable
> it.
>
> llvm-3.7.0-4.fc2{3,4} are building now with the bpf backend enabled,
> I'll create an update for F23 when it's built.

Awesome, thanks!

Re: clang --target=bpf missing on f23 was: Re: [PATCH 1/2] perf test: Add libbpf relocation checker

[Arnaldo Carvalho de Melo]

Em Fri, Jan 22, 2016 at 06:56:02PM +0100, Daniel Borkmann escreveu:
> On 01/22/2016 06:35 PM, Adam Jackson wrote:
> >On Fri, 2016-01-22 at 14:22 -0300, Arnaldo Carvalho de Melo wrote:
> >
> >>	the 'bpf' target for clang is being used together with perf to
> >>build scriptlets into object code that then gets uploaded to the kernel
> >>via sys_bpf(), was the decision not to include 'bpf' just an accident?
> >
> >I wouldn't call it a "decision", that would imply intent. The main
> >reason I explicitly list targets for llvm is to limit the CPU backends
> >to arches Fedora actually runs on (which itself is because I really
> >only care about llvmpipe, and am only touching llvm because it's in my
> >way). Had no idea there was a bpf backend, so never thought to enable
> >it.
> >
> >llvm-3.7.0-4.fc2{3,4} are building now with the bpf backend enabled,
> >I'll create an update for F23 when it's built.
> 
> Awesome, thanks!

Seconded, thanks for the fast response and for adding the bpf target!

Now that is a good, intentional decision 8-)

- Arnaldo

Re: clang --target=bpf missing on f23 was: Re: [PATCH 1/2] perf test: Add libbpf relocation checker

[David Airlie]

----- Original Message -----
> From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
> To: "Adam Jackson" <ajax@redhat.com>
> Cc: "Arnaldo Carvalho de Melo" <acme@kernel.org>, "Wang Nan" <wangnan0@huawei.com>, ast@kernel.org,
> linux-kernel@vger.kernel.org, "Daniel Borkmann" <daniel@iogearbox.net>, "Li Zefan" <lizefan@huawei.com>,
> pi3orama@163.com, "Dave Airlie" <airlied@redhat.com>
> Sent: Saturday, 23 January, 2016 3:42:30 AM
> Subject: Re: clang --target=bpf missing on f23 was:  Re: [PATCH 1/2] perf test: Add libbpf relocation checker
> 
> On Fri, Jan 22, 2016 at 12:35:42PM -0500, Adam Jackson wrote:
> > On Fri, 2016-01-22 at 14:22 -0300, Arnaldo Carvalho de Melo wrote:
> > 
> > > 	the 'bpf' target for clang is being used together with perf to
> > > build scriptlets into object code that then gets uploaded to the kernel
> > > via sys_bpf(), was the decision not to include 'bpf' just an accident?
> > 
> > I wouldn't call it a "decision", that would imply intent. The main
> > reason I explicitly list targets for llvm is to limit the CPU backends
> > to arches Fedora actually runs on (which itself is because I really
> > only care about llvmpipe, and am only touching llvm because it's in my
> > way). Had no idea there was a bpf backend, so never thought to enable
> > it.
> > 
> > llvm-3.7.0-4.fc2{3,4} are building now with the bpf backend enabled,
> > I'll create an update for F23 when it's built.
> 
> thanks.
> if you want to reduce the size of binaries, you can probably disable
> nvptx/amdgcn/r600, since I doubt fedora ships with appropriate sdks
> that can take advantage of that.
> 

amdgcn is the other reason we ship llvm, we could probably drop nvptx.

Dave.

> 

Re: [PATCH 2/2] perf bpf: Check relocation target section

[Wangnan (F)]

On 2016/1/23 1:11, Alexei Starovoitov wrote:
> On Fri, Jan 22, 2016 at 09:27:21AM +0000, Wang Nan wrote:
>> Libbpf should check target section before doing relocation to ensure
>> the relocation is correct. If not, a bug in LLVM causes error. See [1].
>> Also, if an incorrect BPF script uses both global variable and
>> map, global variable whould be treated as map and be relocated
>> without error.
>>
>> This patch saves id of map section into obj->efile and compare
>> target section of a relocation symbol against it during relocation.
> ...
>> [1] https://llvm.org/bugs/show_bug.cgi?id=26243
> ...
>> Signed-off-by: Wang Nan <wangnan0@huawei.com>
>>   
>> +		if (sym.st_shndx != maps_shndx) {
>> +			pr_warning("Program '%s' contains non-map related relo data pointing to section %u\n",
>> +				   prog->section_name, sym.st_shndx);
>> +			return -LIBBPF_ERRNO__RELOC;
>> +		}
> May be 'pr_err' instead of 'pr_warning', since such program will fail
> to load by kernel anyway.

Libbpf doesn't issue pr_error even in fatal exception because it doesn't 
define
pr_err at all. It reports error code and let perf deal with error.

Thank you.

>   Looks good otherwise.
> Acked-by: Alexei Starovoitov <ast@kernel.org>
>

Re: [PATCH 2/2] perf bpf: Check relocation target section

[Wangnan (F)]

On 2016/1/25 9:56, Wangnan (F) wrote:
>
>
> On 2016/1/23 1:11, Alexei Starovoitov wrote:
>> On Fri, Jan 22, 2016 at 09:27:21AM +0000, Wang Nan wrote:
>>> Libbpf should check target section before doing relocation to ensure
>>> the relocation is correct. If not, a bug in LLVM causes error. See [1].
>>> Also, if an incorrect BPF script uses both global variable and
>>> map, global variable whould be treated as map and be relocated
>>> without error.
>>>
>>> This patch saves id of map section into obj->efile and compare
>>> target section of a relocation symbol against it during relocation.
>> ...
>>> [1] https://llvm.org/bugs/show_bug.cgi?id=26243
>> ...
>>> Signed-off-by: Wang Nan <wangnan0@huawei.com>
>>>   +        if (sym.st_shndx != maps_shndx) {
>>> +            pr_warning("Program '%s' contains non-map related relo 
>>> data pointing to section %u\n",
>>> +                   prog->section_name, sym.st_shndx);
>>> +            return -LIBBPF_ERRNO__RELOC;

There's a trailing whitespace. Sorry.

>>> +        }
>> May be 'pr_err' instead of 'pr_warning', since such program will fail
>> to load by kernel anyway.
>
> Libbpf doesn't issue pr_error even in fatal exception because it 
> doesn't define
> pr_err at all. It reports error code and let perf deal with error.
>
> Thank you.
>
>>   Looks good otherwise.
>> Acked-by: Alexei Starovoitov <ast@kernel.org>
>>
>