aboutsummaryrefslogtreecommitdiff
path: root/tools
AgeCommit message (Collapse)AuthorFilesLines
2020-07-17perf tools: Sync hashmap.h with libbpf'sArnaldo Carvalho de Melo1-4/+8
To pick up the changes in: b2f9f1535bb9 ("libbpf: Fix libbpf hashmap on (I)LP32 architectures") Silencing this warning: Warning: Kernel ABI header at 'tools/perf/util/hashmap.h' differs from latest version at 'tools/lib/bpf/hashmap.h' diff -u tools/perf/util/hashmap.h tools/lib/bpf/hashmap.h I'll eventually update the warning to remove the "Kernel ABI" part and instead state libbpf when noticing that the original is at "tools/lib/something". Cc: Adrian Hunter <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andrii Nakryiko <[email protected]> Cc: Jakub Bogusz <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Ian Rogers <[email protected]> Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2020-07-17libsubcmd: Fix OPT_CALLBACK_SET()Ravi Bangoria1-0/+3
Any option macro with _SET suffix should set opt->set variable which is not happening for OPT_CALLBACK_SET(). This is causing issues with perf record --switch-output-event. Fix that. Before: # ./perf record --overwrite -e sched:*switch,syscalls:sys_enter_mmap \ --switch-output-event syscalls:sys_enter_mmap ^C[ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.297 MB perf.data (657 samples) ] After: $ ./perf record --overwrite -e sched:*switch,syscalls:sys_enter_mmap \ --switch-output-event syscalls:sys_enter_mmap [ perf record: dump data: Woken up 1 times ] [ perf record: Dump perf.data.2020061918144542 ] [ perf record: dump data: Woken up 1 times ] [ perf record: Dump perf.data.2020061918144608 ] [ perf record: dump data: Woken up 1 times ] [ perf record: Dump perf.data.2020061918144660 ] ^C[ perf record: dump data: Woken up 1 times ] [ perf record: Dump perf.data.2020061918144784 ] [ perf record: Woken up 0 times to write data ] [ perf record: Dump perf.data.2020061918144803 ] [ perf record: Captured and wrote 0.419 MB perf.data.<timestamp> ] Fixes: 636eb4d001b1 ("libsubcmd: Introduce OPT_CALLBACK_SET()") Signed-off-by: Ravi Bangoria <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Jiri Olsa <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2020-07-17perf metric: Add 'struct expr_id_data' to keep expr valueJiri Olsa4-13/+18
Add 'struct expr_id_data' to keep an expr value instead of just a simple double pointer, so we can store more data for ID in the following changes. Signed-off-by: Jiri Olsa <[email protected]> Acked-by: Ian Rogers <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andi Kleen <[email protected]> Cc: John Garry <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Michael Petlan <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Paul Clarke <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2020-07-17perf metric: Rename expr__add_id() to expr__add_val()Jiri Olsa6-9/+9
Rename expr__add_id() to expr__add_val() so we can use expr__add_id() to actually add just the id without any value in following changes. There's no functional change. Signed-off-by: Jiri Olsa <[email protected]> Acked-by: Ian Rogers <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Andi Kleen <[email protected]> Cc: John Garry <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Michael Petlan <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Paul Clarke <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Stephane Eranian <[email protected]> Link: http://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2020-07-17perf probe: Warn if the target function is a GNU indirect functionMasami Hiramatsu1-2/+6
Warn if the probe target function is a GNU indirect function (GNU_IFUNC) because it may not be what the user wants to probe. The GNU indirect function ( https://sourceware.org/glibc/wiki/GNU_IFUNC ) is the dynamic symbol solved at runtime. An IFUNC function is a selector which is invoked from the ELF loader, but the symbol address of the function which will be modified by the IFUNC is the same as the IFUNC in the symbol table. This can confuse users trying to probe such functions. For example, memcpy is an IFUNC. probe_libc:memcpy (on __new_memcpy_ifunc@x86_64/multiarch/memcpy.c in /usr/lib64/libc-2.30.so) the probe is put on an IFUNC. perf 1742 [000] 26201.715632: probe_libc:memcpy: (7fdaa53824c0) 7fdaa53824c0 __new_memcpy_ifunc+0x0 (inlined) 7fdaa5d4a980 elf_machine_rela+0x6c0 (inlined) 7fdaa5d4a980 elf_dynamic_do_Rela+0x6c0 (inlined) 7fdaa5d4a980 _dl_relocate_object+0x6c0 (/usr/lib64/ld-2.30.so) 7fdaa5d42155 dl_main+0x1cc5 (/usr/lib64/ld-2.30.so) 7fdaa5d5831a _dl_sysdep_start+0x54a (/usr/lib64/ld-2.30.so) 7fdaa5d3ffeb _dl_start_final+0x25b (inlined) 7fdaa5d3ffeb _dl_start+0x25b (/usr/lib64/ld-2.30.so) 7fdaa5d3f117 .annobin_rtld.c+0x7 (inlined) And the event is invoked from the ELF loader instead of the target program's main code. Moreover, at this moment, we can not probe on the function which will be selected by the IFUNC, because it is determined at runtime. But uprobe will be prepared before running the target binary. Thus, I decided to warn user when 'perf probe' detects that the probe point is on an GNU IFUNC symbol. Someone who wants to probe an IFUNC symbol to debug the IFUNC function can ignore this warning. Committer notes: I.e., this warning will be emitted if the probe point is an IFUNC: "Warning: The probe function (%s) is a GNU indirect function.\n" "Consider identifying the final function used at run time and set the probe directly on that.\n" Complete set of steps: # readelf -sW /lib64/libc-2.29.so | grep IFUNC | tail 22196: 0000000000109a80 183 IFUNC GLOBAL DEFAULT 14 __memcpy_chk 22214: 00000000000b7d90 191 IFUNC GLOBAL DEFAULT 14 __gettimeofday 22336: 000000000008b690 60 IFUNC GLOBAL DEFAULT 14 memchr 22350: 000000000008b9b0 89 IFUNC GLOBAL DEFAULT 14 __stpcpy 22420: 000000000008bb10 76 IFUNC GLOBAL DEFAULT 14 __strcasecmp_l 22582: 000000000008a970 60 IFUNC GLOBAL DEFAULT 14 strlen 22585: 00000000000a54d0 92 IFUNC WEAK DEFAULT 14 wmemset 22600: 000000000010b030 92 IFUNC GLOBAL DEFAULT 14 __wmemset_chk 22618: 000000000008b8a0 183 IFUNC GLOBAL DEFAULT 14 __mempcpy 22675: 000000000008ba70 76 IFUNC WEAK DEFAULT 14 strcasecmp # # perf probe -x /lib64/libc-2.29.so strlen Warning: The probe function (strlen) is a GNU indirect function. Consider identifying the final function used at run time and set the probe directly on that. Added new event: probe_libc:strlen (on strlen in /usr/lib64/libc-2.29.so) You can now use it in all perf tools, such as: perf record -e probe_libc:strlen -aR sleep 1 # Reported-by: Andi Kleen <[email protected]> Signed-off-by: Masami Hiramatsu <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Srikar Dronamraju <[email protected]> Link: http://lore.kernel.org/lkml/159438669349.62703.5978345670436126948.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2020-07-17perf probe: Fix memory leakage when the probe point is not foundMasami Hiramatsu1-1/+1
Fix the memory leakage in debuginfo__find_trace_events() when the probe point is not found in the debuginfo. If there is no probe point found in the debuginfo, debuginfo__find_probes() will NOT return -ENOENT, but 0. Thus the caller of debuginfo__find_probes() must check the tf.ntevs and release the allocated memory for the array of struct probe_trace_event. The current code releases the memory only if the debuginfo__find_probes() hits an error but not checks tf.ntevs. In the result, the memory allocated on *tevs are not released if tf.ntevs == 0. This fixes the memory leakage by checking tf.ntevs == 0 in addition to ret < 0. Fixes: ff741783506c ("perf probe: Introduce debuginfo to encapsulate dwarf information") Signed-off-by: Masami Hiramatsu <[email protected]> Reviewed-by: Srikar Dronamraju <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: [email protected] Link: http://lore.kernel.org/lkml/159438668346.62703.10887420400718492503.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2020-07-17perf probe: Fix wrong variable warning when the probe point is not foundMasami Hiramatsu1-0/+3
Fix a wrong "variable not found" warning when the probe point is not found in the debuginfo. Since the debuginfo__find_probes() can return 0 even if it does not find given probe point in the debuginfo, fill_empty_trace_arg() can be called with tf.ntevs == 0 and it can emit a wrong warning. To fix this, reject ntevs == 0 in fill_empty_trace_arg(). E.g. without this patch; # perf probe -x /lib64/libc-2.30.so -a "memcpy arg1=%di" Failed to find the location of the '%di' variable at this address. Perhaps it has been optimized out. Use -V with the --range option to show '%di' location range. Added new events: probe_libc:memcpy (on memcpy in /usr/lib64/libc-2.30.so with arg1=%di) probe_libc:memcpy (on memcpy in /usr/lib64/libc-2.30.so with arg1=%di) You can now use it in all perf tools, such as: perf record -e probe_libc:memcpy -aR sleep 1 With this; # perf probe -x /lib64/libc-2.30.so -a "memcpy arg1=%di" Added new events: probe_libc:memcpy (on memcpy in /usr/lib64/libc-2.30.so with arg1=%di) probe_libc:memcpy (on memcpy in /usr/lib64/libc-2.30.so with arg1=%di) You can now use it in all perf tools, such as: perf record -e probe_libc:memcpy -aR sleep 1 Fixes: cb4027308570 ("perf probe: Trace a magic number if variable is not found") Reported-by: Andi Kleen <[email protected]> Signed-off-by: Masami Hiramatsu <[email protected]> Reviewed-by: Srikar Dronamraju <[email protected]> Tested-by: Andi Kleen <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: [email protected] Link: http://lore.kernel.org/lkml/159438667364.62703.2200642186798763202.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2020-07-17perf probe: Avoid setting probes on the same address for the same eventMasami Hiramatsu1-0/+10
There is a case that several same-name symbols points to the same address. In that case, 'perf probe' returns an error. E.g. # perf probe -x /lib64/libc-2.30.so -v -a "memcpy arg1=%di" probe-definition(0): memcpy arg1=%di symbol:memcpy file:(null) line:0 offset:0 return:0 lazy:(null) parsing arg: arg1=%di into name:arg1 %di 1 arguments symbol:setjmp file:(null) line:0 offset:0 return:0 lazy:(null) symbol:longjmp file:(null) line:0 offset:0 return:0 lazy:(null) symbol:longjmp_target file:(null) line:0 offset:0 return:0 lazy:(null) symbol:lll_lock_wait_private file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_mallopt_arena_max file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_mallopt_arena_test file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_tunable_tcache_max_bytes file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_tunable_tcache_count file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_tunable_tcache_unsorted_limit file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_mallopt_trim_threshold file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_mallopt_top_pad file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_mallopt_mmap_threshold file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_mallopt_mmap_max file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_mallopt_perturb file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_mallopt_mxfast file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_heap_new file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_arena_reuse_free_list file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_arena_reuse file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_arena_reuse_wait file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_arena_new file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_arena_retry file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_sbrk_less file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_heap_free file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_heap_less file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_tcache_double_free file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_heap_more file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_sbrk_more file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_malloc_retry file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_memalign_retry file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_mallopt_free_dyn_thresholds file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_realloc_retry file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_calloc_retry file:(null) line:0 offset:0 return:0 lazy:(null) symbol:memory_mallopt file:(null) line:0 offset:0 return:0 lazy:(null) Open Debuginfo file: /usr/lib/debug/usr/lib64/libc-2.30.so.debug Try to find probe point from debuginfo. Opening /sys/kernel/debug/tracing//README write=0 Failed to find the location of the '%di' variable at this address. Perhaps it has been optimized out. Use -V with the --range option to show '%di' location range. An error occurred in debuginfo analysis (-2). Trying to use symbols. Opening /sys/kernel/debug/tracing//uprobe_events write=1 Writing event: p:probe_libc/memcpy /usr/lib64/libc-2.30.so:0x914c0 arg1=%di Writing event: p:probe_libc/memcpy /usr/lib64/libc-2.30.so:0x914c0 arg1=%di Failed to write event: File exists Error: Failed to add events. Reason: File exists (Code: -17) You can see that perf tried to write completely the same probe definition twice, which caused an error. To fix this issue, check the symbol list and drop duplicated symbols (which has the same symbol name and address) from it. With this patch: # perf probe -x /lib64/libc-2.30.so -a "memcpy arg1=%di" Failed to find the location of the '%di' variable at this address. Perhaps it has been optimized out. Use -V with the --range option to show '%di' location range. Added new events: probe_libc:memcpy (on memcpy in /usr/lib64/libc-2.30.so with arg1=%di) probe_libc:memcpy (on memcpy in /usr/lib64/libc-2.30.so with arg1=%di) You can now use it in all perf tools, such as: perf record -e probe_libc:memcpy -aR sleep 1 Committer notes: Fix this build error on 32-bit arches by using PRIx64 for symbol->start, that is an u64: In file included from util/probe-event.c:27: util/probe-event.c: In function 'find_probe_trace_events_from_map': util/probe-event.c:2978:14: error: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'u64' {aka 'long long unsigned int'} [-Werror=format=] pr_debug("Found duplicated symbol %s @ %lx\n", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ util/debug.h:17:21: note: in definition of macro 'pr_fmt' #define pr_fmt(fmt) fmt ^~~ util/probe-event.c:2978:5: note: in expansion of macro 'pr_debug' pr_debug("Found duplicated symbol %s @ %lx\n", ^~~~~~~~ Reported-by: Andi Kleen <[email protected]> Signed-off-by: Masami Hiramatsu <[email protected]> Reviewed-by: Srikar Dronamraju <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Oleg Nesterov <[email protected]> Link: http://lore.kernel.org/lkml/159438666401.62703.15196394835032087840.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2020-07-16compiler: Remove uninitialized_var() macroKees Cook2-4/+0
Using uninitialized_var() is dangerous as it papers over real bugs[1] (or can in the future), and suppresses unrelated compiler warnings (e.g. "unused variable"). If the compiler thinks it is uninitialized, either simply initialize the variable or make compiler changes. As recommended[2] by[3] Linus[4], remove the macro. With the recent change to disable -Wmaybe-uninitialized in v5.7 in commit 78a5255ffb6a ("Stop the ad-hoc games with -Wno-maybe-initialized"), this is likely the best time to make this treewide change. [1] https://lore.kernel.org/lkml/[email protected]/ [2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/ [3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/ [4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/ Suggested-by: Linus Torvalds <[email protected]> Reviewed-by: Bart van Assche <[email protected]> Reviewed-by: Miguel Ojeda <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Tested-by: Sedat Dilek <[email protected]> Signed-off-by: Kees Cook <[email protected]>
2020-07-16bpf: Drop duplicated words in uapi helper commentsRandy Dunlap1-3/+3
Drop doubled words "will" and "attach". Signed-off-by: Randy Dunlap <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-07-16selftests/bpf: Fix possible hang in sockopt_inheritStanislav Fomichev1-2/+1
Andrii reported that sockopt_inherit occasionally hangs up on 5.5 kernel [0]. This can happen if server_thread runs faster than the main thread. In that case, pthread_cond_wait will wait forever because pthread_cond_signal was executed before the main thread was blocking. Let's move pthread_mutex_lock up a bit to make sure server_thread runs strictly after the main thread goes to sleep. (Not sure why this is 5.5 specific, maybe scheduling is less deterministic? But I was able to confirm that it does indeed happen in a VM.) [0] https://lore.kernel.org/bpf/CAEf4BzY0-bVNHmCkMFPgObs=isUAyg-dFzGDY7QWYkmm7rmTSg@mail.gmail.com/ Reported-by: Andrii Nakryiko <[email protected]> Signed-off-by: Stanislav Fomichev <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-07-16tools/power/x86/intel-speed-select: Update version for v5.9Srinivas Pandruvada1-1/+1
Update version for changes released with v5.9 kernel release. Signed-off-by: Srinivas Pandruvada <[email protected]>
2020-07-16tools/power/x86/intel-speed-select: Add retries for mail box commandsSrinivas Pandruvada1-16/+36
Retry mail box command on failure. The default retry count is 3. This can be changed by "-r|--retry" options. This helps during early bring up of platforms. Signed-off-by: Srinivas Pandruvada <[email protected]>
2020-07-16tools/power/x86/intel-speed-select: Add option to delay mbox commandsSrinivas Pandruvada1-0/+15
Add option "p|--pause" to introduce delay between two mail box commands for test purpose. This delay can be specified in milliseconds. By default there is no delay between two mailbox commands. Signed-off-by: Srinivas Pandruvada <[email protected]>
2020-07-16tools/power/x86/intel-speed-select: Ignore -o option processing on errorSrinivas Pandruvada1-1/+5
When for some reason, CONFIG_TDP_GET_CORE_MASK mailbox command fails, then don't continue online/offline operation for perf-profile set-config-level with "-o" option. Signed-off-by: Srinivas Pandruvada <[email protected]>
2020-07-16tools/power/x86/intel-speed-select: Change path for caching topology infoSrinivas Pandruvada1-2/+4
We want to cache the topology info to a file, which is not preserved across boot cycle. The current storage in /tmp is getting preserved. So change the path from /tmp/isst_cpu_topology.dat to /var/run/isst_cpu_topology.dat. Signed-off-by: Srinivas Pandruvada <[email protected]>
2020-07-16selftest: Add tests for XDP programs in CPUMAP entriesLorenzo Bianconi2-0/+106
Similar to what have been done for DEVMAP, introduce tests to verify ability to add a XDP program to an entry in a CPUMAP. Verify CPUMAP programs can not be attached to devices as a normal XDP program, and only programs with BPF_XDP_CPUMAP attach type can be loaded in a CPUMAP. Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/9c632fcea5382ea7b4578bd06b6eddf382c3550b.1594734381.git.lorenzo@kernel.org
2020-07-16libbpf: Add SEC name for xdp programs attached to CPUMAPLorenzo Bianconi1-0/+2
As for DEVMAP, support SEC("xdp_cpumap/") as a short cut for loading the program with type BPF_PROG_TYPE_XDP and expected attach type BPF_XDP_CPUMAP. Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/33174c41993a6d860d9c7c1f280a2477ee39ed11.1594734381.git.lorenzo@kernel.org
2020-07-16bpf: cpumap: Add the possibility to attach an eBPF program to cpumapLorenzo Bianconi1-0/+5
Introduce the capability to attach an eBPF program to cpumap entries. The idea behind this feature is to add the possibility to define on which CPU run the eBPF program if the underlying hw does not support RSS. Current supported verdicts are XDP_DROP and XDP_PASS. This patch has been tested on Marvell ESPRESSObin using xdp_redirect_cpu sample available in the kernel tree to identify possible performance regressions. Results show there are no observable differences in packet-per-second: $./xdp_redirect_cpu --progname xdp_cpu_map0 --dev eth0 --cpu 1 rx: 354.8 Kpps rx: 356.0 Kpps rx: 356.8 Kpps rx: 356.3 Kpps rx: 356.6 Kpps rx: 356.6 Kpps rx: 356.7 Kpps rx: 355.8 Kpps rx: 356.8 Kpps rx: 356.8 Kpps Co-developed-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: Jesper Dangaard Brouer <[email protected]> Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Link: https://lore.kernel.org/bpf/5c9febdf903d810b3415732e5cd98491d7d9067a.1594734381.git.lorenzo@kernel.org
2020-07-16cpumap: Formalize map value as a named structLorenzo Bianconi1-0/+9
As it has been already done for devmap, introduce 'struct bpf_cpumap_val' to formalize the expected values that can be passed in for a CPUMAP. Update cpumap code to use the struct. Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Jesper Dangaard Brouer <[email protected]> Link: https://lore.kernel.org/bpf/754f950674665dae6139c061d28c1d982aaf4170.1594734381.git.lorenzo@kernel.org
2020-07-15selftests: mlxsw: Test policers' occupancyIdo Schimmel2-0/+113
Test that policers shared by different tc filters are correctly reference counted by observing policers' occupancy via devlink-resource. Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Petr Machata <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-07-15selftests: mlxsw: Add scale test for tc-policeIdo Schimmel5-2/+126
Query the maximum number of supported policers using devlink-resource and test that this number can be reached by configuring tc filters with police action. Test that an error is returned in case the maximum number is exceeded. Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Petr Machata <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-07-15selftests: mlxsw: tc_restrictions: Test tc-police restrictionsIdo Schimmel1-0/+76
Test that upper and lower limits on rate and burst size imposed by the device are rejected by the kernel. Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Petr Machata <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-07-15selftests: forwarding: Add tc-police testsIdo Schimmel1-0/+333
Test tc-police action in various scenarios such as Rx policing, Tx policing, shared policer and police piped to mirred. The test passes with both veth pairs and loopbacked ports. # ./tc_police.sh TEST: police on rx [ OK ] TEST: police on tx [ OK ] TEST: police with shared policer - rx [ OK ] TEST: police with shared policer - tx [ OK ] TEST: police rx and mirror [ OK ] TEST: police tx and mirror [ OK ] Signed-off-by: Ido Schimmel <[email protected]> Reviewed-by: Petr Machata <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2020-07-15tools: usb: usbip: Replace HTTP links with HTTPS onesAlexander A. Klimov1-1/+1
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <[email protected]> Acked-by: Shuah Khan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-07-15selftests/powerpc: Use proper error code to check fault addressHaren Myneni2-4/+4
ERR_NX_TRANSLATION(CSB.CC=5) is for internal to VAS for fault handling and should not used by OS. ERR_NX_AT_FAULT(CSB.CC=250) is the proper error code should be reported by OS when NX encounters address translation failure. This patch uses CC=250 to determine the fault address when the request is not successful. Signed-off-by: Haren Myneni <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-07-15selftests/livepatch: adopt to newer sysctl error formatPetr Mladek2-2/+3
With procfs v3.3.16, the sysctl command doesn't print the set key and value on error. This change breaks livepatch selftest test-ftrace.sh, that tests the interaction of sysctl ftrace_enabled: Make it work with all sysctl versions using '-q' option. Explicitly print the final status on success so that it can be verified in the log. The error message is enough on failure. Reported-by: Kamalesh Babulal <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Reviewed-by: Kamalesh Babulal <[email protected]> Reviewed-by: Joe Lawrence <[email protected]> Acked-by: Miroslav Benes <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-07-15selftests/powerpc: Add FPU denormal testNicholas Piggin3-1/+40
Add a testcase that tries to trigger the FPU denormal exception on Power8 or earlier CPUs. Prior to commit 4557ac6b344b ("powerpc/64s/exception: Fix 0x1500 interrupt handler crash") this would trigger a crash such as: Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: iptable_mangle xt_MASQUERADE iptable_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc ip6table_filter ip6_tables iptable_filter fuse kvm_hv binfmt_misc squashfs mlx4_ib ib_uverbs dm_multipath scsi_dh_rdac scsi_dh_alua ib_core mlx4_en sr_mod cdrom bnx2x lpfc mlx4_core crc_t10dif scsi_transport_fc sg mdio vmx_crypto crct10dif_vpmsum leds_powernv powernv_rng rng_core led_class powernv_op_panel sunrpc ip_tables x_tables autofs4 CPU: 159 PID: 6854 Comm: fpu_denormal Not tainted 5.8.0-rc2-gcc-8.2.0-00092-g4ec7aaab0828 #192 NIP: c0000000000100ec LR: c00000000001b85c CTR: 0000000000000000 REGS: c000001dd818f770 TRAP: 1500 Not tainted (5.8.0-rc2-gcc-8.2.0-00092-g4ec7aaab0828) MSR: 900000000290b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002884 XER: 20000000 CFAR: c00000000001005c IRQMASK: 1 GPR00: c00000000001c4c8 c000001dd818fa00 c00000000171c200 c000001dd8101570 GPR04: 0000000000000000 c000001dd818fe90 c000001dd8101590 000000000000001d GPR08: 0000000000000010 0000000000002000 c000001dd818fe90 fffffffffc48ac60 GPR12: 0000000000002200 c000001ffff4f480 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 00007fffab225b40 0000000000000001 c000000001757168 GPR24: c000001dd8101570 c0000018027b00f0 c000001dd8101570 c000000001496098 GPR28: c00000000174ad05 c000001dd8100000 c000001dd8100000 c000001dd8100000 NIP save_fpu+0xa8/0x2ac LR __giveup_fpu+0x2c/0xd0 Call Trace: 0xc000001dd818fa80 (unreliable) giveup_all+0x118/0x120 __switch_to+0x124/0x6c0 __schedule+0x390/0xaf0 do_task_dead+0x70/0x80 do_exit+0x8fc/0xe10 do_group_exit+0x64/0xd0 sys_exit_group+0x24/0x30 system_call_exception+0x164/0x270 system_call_common+0xf0/0x278 Signed-off-by: Nicholas Piggin <[email protected]> [mpe: Split out of fix patch, add oops log] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-07-14Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller2-14/+14
Alexei Starovoitov says: ==================== pull-request: bpf-next 2020-07-14 The following pull-request contains BPF updates for your *net-next* tree. We've added 21 non-merge commits during the last 1 day(s) which contain a total of 20 files changed, 308 insertions(+), 279 deletions(-). The main changes are: 1) Fix selftests/bpf build, from Alexei. 2) Fix resolve_btfids build issues, from Jiri. 3) Pull usermode-driver-cleanup set, from Eric. 4) Two minor fixes to bpfilter, from Alexei and Masahiro. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-07-14selftests/seccomp: Test SECCOMP_IOCTL_NOTIF_ADDFDSargun Dhillon1-0/+229
Test whether we can add file descriptors in response to notifications. This injects the file descriptors via notifications, and then uses kcmp to determine whether or not it has been successful. It also includes some basic sanity checking for arguments. Signed-off-by: Sargun Dhillon <[email protected]> Cc: Al Viro <[email protected]> Cc: Chris Palmer <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Jann Horn <[email protected]> Cc: Kees Cook <[email protected]> Cc: Robert Sesek <[email protected]> Cc: Tycho Andersen <[email protected]> Cc: Matt Denton <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Co-developed-by: Kees Cook <[email protected]> Signed-off-by: Kees Cook <[email protected]>
2020-07-14selftests: fib_nexthop_multiprefix: fix cleanup() netns deletionPaolo Pisati1-1/+1
During setup(): ... for ns in h0 r1 h1 h2 h3 do create_ns ${ns} done ... while in cleanup(): ... for n in h1 r1 h2 h3 h4 do ip netns del ${n} 2>/dev/null done ... and after removing the stderr redirection in cleanup(): $ sudo ./fib_nexthop_multiprefix.sh ... TEST: IPv4: host 0 to host 3, mtu 1400 [ OK ] TEST: IPv6: host 0 to host 3, mtu 1400 [ OK ] Cannot remove namespace file "/run/netns/h4": No such file or directory $ echo $? 1 and a non-zero return code, make kselftests fail (even if the test itself is fine): ... not ok 34 selftests: net: fib_nexthop_multiprefix.sh # exit=1 ... Signed-off-by: Paolo Pisati <[email protected]> Reviewed-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-14net: bridge: Add port attribute IFLA_BRPORT_MRP_IN_OPENHoratiu Vultur1-0/+1
This patch adds a new port attribute, IFLA_BRPORT_MRP_IN_OPEN, which allows to notify the userspace when the node lost the contiuity of MRP_InTest frames. Signed-off-by: Horatiu Vultur <[email protected]> Acked-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-14bpf: Fix cross build for CONFIG_DEBUG_INFO_BTF optionJiri Olsa1-0/+14
Stephen and 0-DAY CI Kernel Test Service reported broken cross build for arm (arm-linux-gnueabi-gcc (GCC) 9.3.0), with following output: /tmp/ccMS5uth.s: Assembler messages: /tmp/ccMS5uth.s:69: Error: unrecognized symbol type "" /tmp/ccMS5uth.s:82: Error: unrecognized symbol type "" Having '@object' for .type diretive is wrong because '@' is comment character for some architectures. Using STT_OBJECT instead that should work everywhere. Also using HOST* variables to build resolve_btfids so it's properly build in crossbuilds (stolen from objtool's Makefile). Reported-by: kernel test robot <[email protected]> Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-07-14selftests/livepatch: Use "comm" instead of "diff" for dmesgJoe Lawrence1-1/+1
BusyBox diff doesn't support the GNU diff '--LTYPE-line-format' options that were used in the selftests to filter older kernel log messages from dmesg output. Use "comm" which is more available in smaller boot environments. Reported-by: Naresh Kamboju <[email protected]> Signed-off-by: Joe Lawrence <[email protected]> Reviewed-by: Yannick Cote <[email protected]> Reviewed-by: Kamalesh Babulal <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-07-13selftests/bpf: Fix merge conflict resolutionAlexei Starovoitov1-14/+0
Remove double definition of structs. Fixes: 71930d61025e ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net") Signed-off-by: Alexei Starovoitov <[email protected]>
2020-07-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller32-147/+1509
Alexei Starovoitov says: ==================== pull-request: bpf-next 2020-07-13 The following pull-request contains BPF updates for your *net-next* tree. We've added 36 non-merge commits during the last 7 day(s) which contain a total of 62 files changed, 2242 insertions(+), 468 deletions(-). The main changes are: 1) Avoid trace_printk warning banner by switching bpf_trace_printk to use its own tracing event, from Alan. 2) Better libbpf support on older kernels, from Andrii. 3) Additional AF_XDP stats, from Ciara. 4) build time resolution of BTF IDs, from Jiri. 5) BPF_CGROUP_INET_SOCK_RELEASE hook, from Stanislav. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-07-13selftests: mlxsw: RED: Test offload of mirror on RED early_drop qeventPetr Machata3-3/+122
Add a selftest for offloading a mirror action attached to the block associated with RED early_drop qevent. Signed-off-by: Petr Machata <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-07-13tools/bpftool: Strip away modifiers from global variablesAndrii Nakryiko4-19/+18
Reliably remove all the type modifiers from read-only (.rodata) global variable definitions, including cases of inner field const modifiers and arrays of const values. Also modify one of selftests to ensure that const volatile struct doesn't prevent user-space from modifying .rodata variable. Fixes: 985ead416df3 ("bpftool: Add skeleton codegen command") Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-07-13libbpf: Support stripping modifiers for btf_dumpAndrii Nakryiko2-2/+10
One important use case when emitting const/volatile/restrict is undesirable is BPF skeleton generation of DATASEC layout. These are further memory-mapped and can be written/read from user-space directly. For important case of .rodata variables, bpftool strips away first-level modifiers, to make their use on user-space side simple and not requiring extra type casts to override compiler complaining about writing to const variables. This logic works mostly fine, but breaks in some more complicated cases. E.g.: const volatile int params[10]; Because in BTF it's a chain of ARRAY -> CONST -> VOLATILE -> INT, bpftool stops at ARRAY and doesn't strip CONST and VOLATILE. In skeleton this variable will be emitted as is. So when used from user-space, compiler will complain about writing to const array. This is problematic, as also mentioned in [0]. To solve this for arrays and other non-trivial cases (e.g., inner const/volatile fields inside the struct), teach btf_dump to strip away any modifier, when requested. This is done as an extra option on btf_dump__emit_type_decl() API. Reported-by: Anton Protopopov <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-07-13selftests/bpf: Add selftests verifying bpf_trace_printk() behaviourAlan Maguire2-0/+96
Simple selftests that verifies bpf_trace_printk() returns a sensible value and tracing messages appear. Signed-off-by: Alan Maguire <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-07-13tools/bpftool: Remove warning about PID iterator supportAndrii Nakryiko1-1/+0
Don't emit warning that bpftool was built without PID iterator support. This error garbles JSON output of otherwise perfectly valid show commands. Reported-by: Andrey Ignatov <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-07-13xsk: Add new statisticsCiara Loftus1-1/+4
It can be useful for the user to know the reason behind a dropped packet. Introduce new counters which track drops on the receive path caused by: 1. rx ring being full 2. fill ring being empty Also, on the tx path introduce a counter which tracks the number of times we attempt pull from the tx ring when it is empty. Signed-off-by: Ciara Loftus <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-07-13selftests/bpf: Add test for resolve_btfidsJiri Olsa3-1/+175
Adding resolve_btfids test under test_progs suite. It's possible to use btf_ids.h header and its logic in user space application, so we can add easy test for it. The test defines BTF_ID_LIST and checks it gets properly resolved. For this reason the test_progs binary (and other binaries that use TRUNNER* macros) is processed with resolve_btfids tool, which resolves BTF IDs in .BTF_ids section. The BTF data are taken from btf_data.o object rceated from progs/btf_data.c. Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Tested-by: Andrii Nakryiko <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-07-13tools headers: Adopt verbatim copy of btf_ids.h from kernel sourcesJiri Olsa2-0/+91
It will be needed by bpf selftest for resolve_btfids tool. Also adding __PASTE macro as btf_ids.h dependency, which is defined in: include/linux/compiler_types.h but because tools/include do not have this header, I'm putting the macro into linux/compiler.h header. Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Tested-by: Andrii Nakryiko <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-07-13bpf: Compile resolve_btfids tool at kernel compilation startJiri Olsa2-1/+11
The resolve_btfids tool will be used during the vmlinux linking, so it's necessary it's ready for it. Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Tested-by: Andrii Nakryiko <[email protected]> Acked-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-07-13bpf: Add resolve_btfids tool to resolve BTF IDs in ELF objectJiri Olsa3-0/+808
The resolve_btfids tool scans elf object for .BTF_ids section and resolves its symbols with BTF ID values. It will be used to during linking time to resolve arrays of BTF ID values used in verifier, so these IDs do not need to be resolved in runtime. The expected layout of .BTF_ids section is described in main.c header. Related kernel changes are coming in following changes. Build issue reported by 0-DAY CI Kernel Test Service. Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2020-07-12tools: gpio: fix spurious close warning in gpio-event-monKent Gibson1-1/+2
Fix bogus close warning that occurs when opening the character device fails. Signed-off-by: Kent Gibson <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-07-12tools: gpio: fix spurious close warning in gpio-utilsKent Gibson1-2/+2
Fix bogus close warning that occurs when opening the character device fails. Signed-off-by: Kent Gibson <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-07-12tools: gpio: fix spurious close warning in lsgpioKent Gibson1-1/+2
Fix bogus close warning that occurs when opening the character device fails. Signed-off-by: Kent Gibson <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
2020-07-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netDavid S. Miller58-260/+631
All conflicts seemed rather trivial, with some guidance from Saeed Mameed on the tc_ct.c one. Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.