kernel/linux.git/tools, branch v4.19.51

objtool: Don't use ignore flag for fake jumps

2019-06-15T09:54:03+00:00

[ Upstream commit e6da9567959e164f82bc81967e0d5b10dee870b4 ] The ignore flag is set on fake jumps in order to keep add_jump_destinations() from setting their jump_dest, since it already got set when the fake jump was created. But using the ignore flag is a bit of a hack. It's normally used to skip validation of an instruction, which doesn't really make sense for fake jumps. Also, after the next patch, using the ignore flag for fake jumps can trigger a false "why am I validating an ignored function?" warning. Instead just add an explicit check in add_jump_destinations() to skip fake jumps. Signed-off-by: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/71abc072ff48b2feccc197723a9c52859476c068.1557766718.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin

jump_label: move 'asm goto' support test to Kconfig

2019-06-04T06:02:34+00:00

commit e9666d10a5677a494260d60d1fa0b73cc7646eb3 upstream. Currently, CONFIG_JUMP_LABEL just means "I _want_ to use jump label". The jump label is controlled by HAVE_JUMP_LABEL, which is defined like this: #if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL) # define HAVE_JUMP_LABEL #endif We can improve this by testing 'asm goto' support in Kconfig, then make JUMP_LABEL depend on CC_HAS_ASM_GOTO. Ugly #ifdef HAVE_JUMP_LABEL will go away, and CONFIG_JUMP_LABEL will match to the real kernel capability. Signed-off-by: Masahiro Yamada Acked-by: Michael Ellerman (powerpc) Tested-by: Sedat Dilek [nc: Fix trivial conflicts in 4.19 arch/xtensa/kernel/jump_label.c doesn't exist yet Ensured CC_HAVE_ASM_GOTO and HAVE_JUMP_LABEL were sufficiently eliminated] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

selftests/bpf: ksym_search won't check symbols exists

2019-05-31T13:46:25+00:00

[ Upstream commit 0979ff7992fb6f4eb837995b12f4071dcafebd2d ] Currently, ksym_search located at trace_helpers won't check symbols are existing or not. In ksym_search, when symbol is not found, it will return &syms[0](_stext). But when the kernel symbols are not loaded, it will return NULL, which is not a desired action. This commit will add verification logic whether symbols are loaded prior to the symbol search. Signed-off-by: Daniel T. Lee Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin

selftests: cgroup: fix cleanup path in test_memcg_subtree_control()

2019-05-31T13:46:24+00:00

[ Upstream commit e14d314c7a489f060d6d691866fef5f131281718 ] Dan reported, that cleanup path in test_memcg_subtree_control() triggers a static checker warning: ./tools/testing/selftests/cgroup/test_memcontrol.c:76 \ test_memcg_subtree_control() error: uninitialized symbol 'child2'. Fix this by initializing child2 and parent2 variables and split the cleanup path into few stages. Signed-off-by: Roman Gushchin Fixes: 84092dbcf901 ("selftests: cgroup: add memory controller self-tests") Reported-by: Dan Carpenter Cc: Dan Carpenter Cc: Shuah Khan (Samsung OSG) Cc: Mike Rapoport Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin

libbpf: fix samples/bpf build failure due to undefined UINT32_MAX

2019-05-31T13:46:14+00:00

[ Upstream commit 32e621e55496a0009f44fe4914cd4a23cade4984 ] Currently, building bpf samples will cause the following error. ./tools/lib/bpf/bpf.h:132:27: error: 'UINT32_MAX' undeclared here (not in a function) .. #define BPF_LOG_BUF_SIZE (UINT32_MAX >> 8) /* verifier maximum in kernels <= 5.1 */ ^ ./samples/bpf/bpf_load.h:31:25: note: in expansion of macro 'BPF_LOG_BUF_SIZE' extern char bpf_log_buf[BPF_LOG_BUF_SIZE]; ^~~~~~~~~~~~~~~~ Due to commit 4519efa6f8ea ("libbpf: fix BPF_LOG_BUF_SIZE off-by-one error") hard-coded size of BPF_LOG_BUF_SIZE has been replaced with UINT32_MAX which is defined in header. Even with this change, bpf selftests are running fine since these are built with clang and it includes header(-idirafter) from clang/6.0.0/include. (it has ) clang -I. -I./include/uapi -I../../../include/uapi -idirafter /usr/local/include -idirafter /usr/include \ -idirafter /usr/lib/llvm-6.0/lib/clang/6.0.0/include -idirafter /usr/include/x86_64-linux-gnu \ -Wno-compare-distinct-pointer-types -O2 -target bpf -emit-llvm -c progs/test_sysctl_prog.c -o - | \ llc -march=bpf -mcpu=generic -filetype=obj -o /linux/tools/testing/selftests/bpf/test_sysctl_prog.o But bpf samples are compiled with GCC, and it only searches and includes headers declared at the target file. As '#include ' hasn't been declared in tools/lib/bpf/bpf.h, it causes build failure of bpf samples. gcc -Wp,-MD,./samples/bpf/.sockex3_user.o.d -Wall -Wmissing-prototypes -Wstrict-prototypes \ -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include -I./tools/lib/ -I./tools/testing/selftests/bpf/ \ -I./tools/ lib/ -I./tools/include -I./tools/perf -c -o ./samples/bpf/sockex3_user.o ./samples/bpf/sockex3_user.c; This commit add declaration of '#include ' to tools/lib/bpf/bpf.h to fix this problem. Signed-off-by: Daniel T. Lee Acked-by: Yonghong Song Signed-off-by: Daniel Borkmann Signed-off-by: Sasha Levin

bpftool: exclude bash-completion/bpftool from .gitignore pattern

2019-05-31T13:46:08+00:00

[ Upstream commit a7d006714724de4334c5e3548701b33f7b12ca96 ] tools/bpf/bpftool/.gitignore has the "bpftool" pattern, which is intended to ignore the following build artifact: tools/bpf/bpftool/bpftool However, the .gitignore entry is effective not only for the current directory, but also for any sub-directories. So, from the point of .gitignore grammar, the following check-in file is also considered to be ignored: tools/bpf/bpftool/bash-completion/bpftool As the manual gitignore(5) says "Files already tracked by Git are not affected", this is not a problem as far as Git is concerned. However, Git is not the only program that parses .gitignore because .gitignore is useful to distinguish build artifacts from source files. For example, tar(1) supports the --exclude-vcs-ignore option. As of writing, this option does not work perfectly, but it intends to create a tarball excluding files specified by .gitignore. So, I believe it is better to fix this issue. You can fix it by prefixing the pattern with a slash; the leading slash means the specified pattern is relative to the current directory. Signed-off-by: Masahiro Yamada Reviewed-by: Quentin Monnet Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

selftests/bpf: set RLIMIT_MEMLOCK properly for test_libbpf_open.c

2019-05-31T13:46:08+00:00

[ Upstream commit 6cea33701eb024bc6c920ab83940ee22afd29139 ] Test test_libbpf.sh failed on my development server with failure -bash-4.4$ sudo ./test_libbpf.sh [0] libbpf: Error in bpf_object__probe_name():Operation not permitted(1). Couldn't load basic 'r0 = 0' BPF program. test_libbpf: failed at file test_l4lb.o selftests: test_libbpf [FAILED] -bash-4.4$ The reason is because my machine has 64KB locked memory by default which is not enough for this program to get locked memory. Similar to other bpf selftests, let us increase RLIMIT_MEMLOCK to infinity, which fixed the issue. Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

tools/bpf: fix perf build error with uClibc (seen on ARC)

2019-05-31T13:46:08+00:00

[ Upstream commit ca31ca8247e2d3807ff5fa1d1760616a2292001c ] When build perf for ARC recently, there was a build failure due to lack of __NR_bpf. | Auto-detecting system features: | | ... get_cpuid: [ OFF ] | ... bpf: [ on ] | | # error __NR_bpf not defined. libbpf does not support your arch. ^~~~~ | bpf.c: In function 'sys_bpf': | bpf.c:66:17: error: '__NR_bpf' undeclared (first use in this function) | return syscall(__NR_bpf, cmd, attr, size); | ^~~~~~~~ | sys_bpf Signed-off-by: Vineet Gupta Acked-by: Yonghong Song Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin

Revert "selftests/bpf: skip verifier tests for unsupported program types"

2019-05-25T16:23:47+00:00

This reverts commit 118d38a3577f7728278f6afda8436af05a6bec7f which is commit 8184d44c9a577a2f1842ed6cc844bfd4a9981d8e upstream. Tommi reports that this patch breaks the build, it's not really needed so let's revert it. Reported-by: Tommi Rantala Cc: Stanislav Fomichev Cc: Sasha Levin Acked-by: Daniel Borkmann Signed-off-by: Greg Kroah-Hartman

perf bench numa: Add define for RUSAGE_THREAD if not present

2019-05-25T16:23:46+00:00

[ Upstream commit bf561d3c13423fc54daa19b5d49dc15fafdb7acc ] While cross building perf to the ARC architecture on a fedora 30 host, we were failing with: CC /tmp/build/perf/bench/numa.o bench/numa.c: In function ‘worker_thread’: bench/numa.c:1261:12: error: ‘RUSAGE_THREAD’ undeclared (first use in this function); did you mean ‘SIGEV_THREAD’? getrusage(RUSAGE_THREAD, &rusage); ^~~~~~~~~~~~~ SIGEV_THREAD bench/numa.c:1261:12: note: each undeclared identifier is reported only once for each function it appears in [perfbuilder@60d5802468f6 perf]$ /arc_gnu_2019.03-rc1_prebuilt_uclibc_le_archs_linux_install/bin/arc-linux-gcc --version | head -1 arc-linux-gcc (ARCv2 ISA Linux uClibc toolchain 2019.03-rc1) 8.3.1 20190225 [perfbuilder@60d5802468f6 perf]$ Trying to reproduce a report by Vineet, I noticed that, with just cross-built zlib and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define, check for that and numactl libraries, I ended up with the above failure. So, since RUSAGE_THREAD is available as a define in the system headers, check if it is defined in the 'perf bench numa' sources and define it if not. Now it builds and I have to figure out if the problem reported by Vineet only takes place if we have libelf or some other library available. Cc: Arnd Bergmann Cc: Jiri Olsa Cc: linux-snps-arc@lists.infradead.org Cc: Namhyung Kim Cc: Vineet Gupta Link: https://lkml.kernel.org/n/tip-2wb4r1gir9xrevbpq7qp0amk@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin