- 12 Apr, 2023 23 commits
-
-
Tiezhu Yang authored
After commit 1f265d2a ("selftests/bpf: Remove not used headers"), tools/arch/s390/include/uapi/asm/ptrace.h has been removed, so remove it in check-headers.sh too, otherwise we can see the following build warning: diff: tools/arch/s390/include/uapi/asm/ptrace.h: No such file or directory Fixes: 1f265d2a ("selftests/bpf: Remove not used headers") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Jiri Olsa <jolsa@kernel.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: Tiezhu Yang <yangtiezhu@loongson.cn> Cc: bpf@vger.kernel.org Cc: loongson-kernel@lists.loongnix.cn Link: https://lore.kernel.org/oe-kbuild-all/202304050029.38NdbQPf-lkp@intel.com/ Link: https://lore.kernel.org/r/1680834090-2322-1-git-send-email-yangtiezhu@loongson.cnSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Arnaldo Carvalho de Melo authored
An audit showed just this one problem with zfree(), fix it. Fixes: 9fbc61f8 ("perf pmu: Add support for PMU capabilities") Signed-off-by:
-
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. This file already used zfree() in other places, so this just plugs some leftovers. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Also include the missing linux/zalloc.h header directive. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Also remove one NULL test before free(), as it accepts a NULL arg and we get one line shaved not doing it explicitely. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Also remove one NULL test before free(), as it accepts a NULL arg and we get one line shaved not doing it explicitely. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Also remove one NULL test before free(), as it accepts a NULL arg and we get one line shaved not doing it explicitely. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Arnaldo Carvalho de Melo authored
Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: -
Ian Rogers authored
Update from v1.19 to v1.20 affecting the uncore UNC_CHA_CORE_SNP.REMOTE_GTONE event's umask. Signed-off-by:
Ian Rogers <irogers@google.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Xing Zhengjun <zhengjun.xing@linux.intel.com> Link: https://lore.kernel.org/r/20230411234440.3313680-2-irogers@google.comSigned-off-by:
-
Ian Rogers authored
Update from v1.19 to v1.20 affecting the performance/goldencove events. Adds cmask=1 for ARITH.IDIV_ACTIVE, and updates event descriptions. Signed-off-by:
-
- 11 Apr, 2023 2 commits
-
-
Ian Rogers authored
If bperf (perf tools that use BPF skels) sets evsel->leader_skel or evsel->follower_skel then it appears that evsel->bpf_skel is set and can trigger the following use-after-free: ==13575==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000014080 at pc 0x55684b939880 bp 0x7ffdfcf30d70 sp 0x7ffdfcf30d68 READ of size 8 at 0x60c000014080 thread T0 #0 0x55684b93987f in sample_filter_bpf__destroy tools/perf/bpf_skel/sample_filter.skel.h:44:11 #1 0x55684b93987f in perf_bpf_filter__destroy tools/perf/util/bpf-filter.c:155:2 #2 0x55684b98f71e in evsel__exit tools/perf/util/evsel.c:1521:2 #3 0x55684b98a352 in evsel__delete tools/perf/util/evsel.c:1547:2 #4 0x55684b981918 in evlist__purge tools/perf/util/evlist.c:148:3 #5 0x55684b981918 in evlist__delete tools/perf/util/evlist.c:169:2 #6 0x55684b887d60 in cmd_stat tools/perf/builtin-stat.c:2598:2 .. 0x60c000014080 is located 0 bytes inside of 128-byte region [0x60c000014080,0x60c000014100) freed by thread T0 here: #0 0x55684b780e86 in free compiler-rt/lib/asan/asan_malloc_linux.cpp:52:3 #1 0x55684b9462da in bperf_cgroup_bpf__destroy tools/perf/bpf_skel/bperf_cgroup.skel.h:61:2 #2 0x55684b9462da in bperf_cgrp__destroy tools/perf/util/bpf_counter_cgroup.c:282:2 #3 0x55684b944c75 in bpf_counter__destroy tools/perf/util/bpf_counter.c:819:2 #4 0x55684b98f716 in evsel__exit tools/perf/util/evsel.c:1520:2 #5 0x55684b98a352 in evsel__delete tools/perf/util/evsel.c:1547:2 #6 0x55684b981918 in evlist__purge tools/perf/util/evlist.c:148:3 #7 0x55684b981918 in evlist__delete tools/perf/util/evlist.c:169:2 #8 0x55684b887d60 in cmd_stat tools/perf/builtin-stat.c:2598:2 ... previously allocated by thread T0 here: #0 0x55684b781338 in calloc compiler-rt/lib/asan/asan_malloc_linux.cpp:77:3 #1 0x55684b944e25 in bperf_cgroup_bpf__open_opts tools/perf/bpf_skel/bperf_cgroup.skel.h:73:35 #2 0x55684b944e25 in bperf_cgroup_bpf__open tools/perf/bpf_skel/bperf_cgroup.skel.h:97:9 #3 0x55684b944e25 in bperf_load_program tools/perf/util/bpf_counter_cgroup.c:55:9 #4 0x55684b944e25 in bperf_cgrp__load tools/perf/util/bpf_counter_cgroup.c:178:23 #5 0x55684b889289 in __run_perf_stat tools/perf/builtin-stat.c:713:7 #6 0x55684b889289 in run_perf_stat tools/perf/builtin-stat.c:949:8 #7 0x55684b888029 in cmd_stat tools/perf/builtin-stat.c:2537:12 Resolve by clearing 'evsel->bpf_skel' as part of bpf_counter__destroy(). Suggested-by:Namhyung Kim <namhyung@kernel.org> Signed-off-by:
-
Ian Rogers authored
Seen in "perf stat --bpf-counters --for-each-cgroup test" running in a container: libbpf: Failed to bump RLIMIT_MEMLOCK (err = -1), you might need to do it explicitly! libbpf: Error in bpf_object__probe_loading():Operation not permitted(1). Couldn't load trivial BPF program. Make sure your kernel supports BPF (CONFIG_BPF_SYSCALL=y) and/or that RLIMIT_MEMLOCK is set to big enough value. libbpf: failed to load object 'bperf_cgroup_bpf' libbpf: failed to load BPF skeleton 'bperf_cgroup_bpf': -1 Failed to load cgroup skeleton #0 0x55f28a650981 in list_empty tools/include/linux/list.h:189 #1 0x55f28a6593b4 in evsel__exit util/evsel.c:1518 #2 0x55f28a6596af in evsel__delete util/evsel.c:1544 #3 0x55f28a89d166 in bperf_cgrp__destroy util/bpf_counter_cgroup.c:283 #4 0x55f28a899e9a in bpf_counter__destroy util/bpf_counter.c:816 #5 0x55f28a659455 in evsel__exit util/evsel.c:1520 #6 0x55f28a6596af in evsel__delete util/evsel.c:1544 #7 0x55f28a640d4d in evlist__purge util/evlist.c:148 #8 0x55f28a640ea6 in evlist__delete util/evlist.c:169 #9 0x55f28a4efbf2 in cmd_stat tools/perf/builtin-stat.c:2598 #10 0x55f28a6050c2 in run_builtin tools/perf/perf.c:330 #11 0x55f28a605633 in handle_internal_command tools/perf/perf.c:384 #12 0x55f28a6059fb in run_argv tools/perf/perf.c:428 #13 0x55f28a6061d3 in main tools/perf/perf.c:562 Signed-off-by:
-
- 10 Apr, 2023 15 commits
-
-
Ravi Bangoria authored
perf script ibs: Change bit description according to latest AMD PPR ("Processor Programming Reference") Some of the IBS_OP_DATA2 bit descriptions were stale (taken from old version of PPR). Change it according to latest PPR. Signed-off-by:Ravi Bangoria <ravi.bangoria@amd.com> Acked-by:
-
Ravi Bangoria authored
39 is taken from the length of longest printable new API string: "Remote socket, same board Any cache hit". Although, using old API can result into even longer strings, let's not overkill by making it dynamic length. Signed-off-by:
-
Ravi Bangoria authored
Interpretation of 'union perf_mem_data_src' by perf_mem__lvl_scnprintf() is non-intuitive. For ex, it ignores 'mem_lvl' when 'mem_hops' is set but considers it otherwise. It prints both 'mem_lvl_num' and 'mem_lvl' when 'mem_hops' is not set. Refactor this function such that it behaves more intuitively: Use new API 'mem_lvl_num'|'mem_remote'|'mem_hops' if 'mem_lvl_num' contains value other than PERF_MEM_LVLNUM_NA. Otherwise, fallback to old API 'mem_lvl'. Since new API has no way to indicate MISS, use it from old api, otherwise don't club old and new APIs while parsing as well as printing. Before: $ sudo ./perf mem report -F sample,mem --stdio # Samples Memory access # ............ ........................ # 250097 N/A 188907 L1 hit 4116 L2 hit 3496 Remote Cache (1 hop) hit 3271 Remote Cache (2 hops) hit 873 L3 hit 598 Local RAM hit 438 Remote RAM (1 hop) hit 1 Uncached hit After: $ sudo ./perf mem report -F sample,mem --stdio # Samples Memory access # ............ ....................................... # 255517 N/A 189989 L1 hit 4541 L2 hit 3363 Remote core, same node Any cache hit 3336 Remote node, same socket Any cache hit 1275 L3 hit 743 RAM hit 545 Remote node, same socket RAM hit 4 Uncached hit Signed-off-by: -
Ravi Bangoria authored
Add support for printing PERF_MEM_LVLNUM_UNC in perf mem report. Signed-off-by:
-
Ravi Bangoria authored
Add PERF_MEM_LVLNUM_NA wherever PERF_MEM_DATA_SRC_NONE is used to set default values. Signed-off-by:
-
Ravi Bangoria authored
... to bring PERF_MEM_LVLNUM_UNC definition to userspace Signed-off-by:
-
Ian Rogers authored
Done as a warning as I'm not fully confident of the test's robustness of comparing the macro definition of __BYTE_ORDER__. v2. Is a rebase following patch 1 being merged. Signed-off-by:
-
Ian Rogers authored
The definitions are in util.c so move the declarations to match. Signed-off-by:
-
Ian Rogers authored
'input_name' is the name of the input perf.data file, it is used by data convert and ui code. Move it to util to make it more consistent with other global state. Signed-off-by:
-
Ian Rogers authored
Remove additional version_verbose flag by using the existing verbose variable. Signed-off-by:
-
Ian Rogers authored
Move to match the definition in header.c. Signed-off-by:
-
Ian Rogers authored
The usage function is part of util.h, move the usage strings there too. Signed-off-by:
-
Ian Rogers authored
Move under tools/perf/ui rather than in perf.c. Signed-off-by:
-
Ian Rogers authored
Write the JSON output to a file, then sanity check this output. This avoids problems with debug/warning/error output corrupting the file format. Signed-off-by:
-
Ian Rogers authored
JSON files don't support comments. Disable the "started on" comment when writing json output to file. Signed-off-by:
-
