1. 25 9月, 2019 3 次提交
  2. 21 9月, 2019 1 次提交
    • J
      perf tools: Fix segfault in cpu_cache_level__read() · 0216234c
      Jiri Olsa 提交于
      We release wrong pointer on error path in cpu_cache_level__read
      function, leading to segfault:
      
        (gdb) r record ls
        Starting program: /root/perf/tools/perf/perf record ls
        ...
        [ perf record: Woken up 1 times to write data ]
        double free or corruption (out)
      
        Thread 1 "perf" received signal SIGABRT, Aborted.
        0x00007ffff7463798 in raise () from /lib64/power9/libc.so.6
        (gdb) bt
        #0  0x00007ffff7463798 in raise () from /lib64/power9/libc.so.6
        #1  0x00007ffff7443bac in abort () from /lib64/power9/libc.so.6
        #2  0x00007ffff74af8bc in __libc_message () from /lib64/power9/libc.so.6
        #3  0x00007ffff74b92b8 in malloc_printerr () from /lib64/power9/libc.so.6
        #4  0x00007ffff74bb874 in _int_free () from /lib64/power9/libc.so.6
        #5  0x0000000010271260 in __zfree (ptr=0x7fffffffa0b0) at ../../lib/zalloc..
        #6  0x0000000010139340 in cpu_cache_level__read (cache=0x7fffffffa090, cac..
        #7  0x0000000010143c90 in build_caches (cntp=0x7fffffffa118, size=<optimiz..
        ...
      
      Releasing the proper pointer.
      
      Fixes: 720e98b5 ("perf tools: Add perf data cache feature")
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: stable@vger.kernel.org: # v4.6+
      Link: http://lore.kernel.org/lkml/20190912105235.10689-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0216234c
  3. 20 9月, 2019 3 次提交
  4. 01 9月, 2019 1 次提交
  5. 30 8月, 2019 3 次提交
  6. 29 8月, 2019 3 次提交
  7. 14 8月, 2019 1 次提交
    • T
      perf record: Support aarch64 random socket_id assignment · 0a4d8fb2
      Tan Xiaojun 提交于
      Same as in the commit 01766229 ("perf record: Support s390 random
      socket_id assignment"), aarch64 also have this problem.
      
      Without this fix:
      
        [root@localhost perf]# ./perf report --header -I -v
        ...
        socket_id number is too big.You may need to upgrade the perf tool.
      
        # ========
        # captured on    : Thu Aug  1 22:58:38 2019
        # header version : 1
        ...
        # Core ID and Socket ID information is not available
        ...
      
      With this fix:
        [root@localhost perf]# ./perf report --header -I -v
        ...
        cpumask list: 0-31
        cpumask list: 32-63
        cpumask list: 64-95
        cpumask list: 96-127
      
        # ========
        # captured on    : Thu Aug  1 22:58:38 2019
        # header version : 1
        ...
        # CPU 0: Core ID 0, Socket ID 36
        # CPU 1: Core ID 1, Socket ID 36
        ...
        # CPU 126: Core ID 126, Socket ID 8442
        # CPU 127: Core ID 127, Socket ID 8442
        ...
      Signed-off-by: NTan Xiaojun <tanxiaojun@huawei.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
      Link: http://lkml.kernel.org/r/1564717737-21602-1-git-send-email-tanxiaojun@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0a4d8fb2
  8. 30 7月, 2019 13 次提交
  9. 29 7月, 2019 2 次提交
    • N
      perf header: Fix use of unitialized value warning · 20f9781f
      Numfor Mbiziwo-Tiapo 提交于
      When building our local version of perf with MSAN (Memory Sanitizer) and
      running the perf record command, MSAN throws a use of uninitialized
      value warning in "tools/perf/util/util.c:333:6".
      
      This warning stems from the "buf" variable being passed into "write".
      It originated as the variable "ev" with the type union perf_event*
      defined in the "perf_event__synthesize_attr" function in
      "tools/perf/util/header.c".
      
      In the "perf_event__synthesize_attr" function they allocate space with a malloc
      call using ev, then go on to only assign some of the member variables before
      passing "ev" on as a parameter to the "process" function therefore "ev"
      contains uninitialized memory. Changing the malloc call to zalloc to initialize
      all the members of "ev" which gets rid of the warning.
      
      To reproduce this warning, build perf by running:
      make -C tools/perf CLANG=1 CC=clang EXTRA_CFLAGS="-fsanitize=memory\
       -fsanitize-memory-track-origins"
      
      (Additionally, llvm might have to be installed and clang might have to
      be specified as the compiler - export CC=/usr/bin/clang)
      
      then running:
      tools/perf/perf record -o - ls / | tools/perf/perf --no-pager annotate\
       -i - --stdio
      
      Please see the cover letter for why false positive warnings may be
      generated.
      Signed-off-by: NNumfor Mbiziwo-Tiapo <nums@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mark Drayton <mbd@fb.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/20190724234500.253358-2-nums@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      20f9781f
    • V
      perf header: Fix divide by zero error if f_header.attr_size==0 · 7622236c
      Vince Weaver 提交于
      So I have been having lots of trouble with hand-crafted perf.data files
      causing segfaults and the like, so I have started fuzzing the perf tool.
      
      First issue found:
      
      If f_header.attr_size is 0 in the perf.data file, then perf will crash
      with a divide-by-zero error.
      
      Committer note:
      
      Added a pr_err() to tell the user why the command failed.
      Signed-off-by: NVince Weaver <vincent.weaver@maine.edu>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1907231100440.14532@macbook-airSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7622236c
  10. 23 7月, 2019 1 次提交
  11. 09 7月, 2019 2 次提交
  12. 07 7月, 2019 1 次提交
    • S
      perf header: Assign proper ff->ph in perf_event__synthesize_features() · c952b35f
      Song Liu 提交于
      bpf/btf write_* functions need ff->ph->env.
      
      With this missing, pipe-mode (perf record -o -)  would crash like:
      
      Program terminated with signal SIGSEGV, Segmentation fault.
      
      This patch assign proper ph value to ff.
      
      Committer testing:
      
        (gdb) run record -o -
        Starting program: /root/bin/perf record -o -
        PERFILE2
        <SNIP start of perf.data headers>
        Thread 1 "perf" received signal SIGSEGV, Segmentation fault.
        __do_write_buf (size=4, buf=0x160, ff=0x7fffffff8f80) at util/header.c:126
        126		memcpy(ff->buf + ff->offset, buf, size);
        (gdb) bt
        #0  __do_write_buf (size=4, buf=0x160, ff=0x7fffffff8f80) at util/header.c:126
        #1  do_write (ff=ff@entry=0x7fffffff8f80, buf=buf@entry=0x160, size=4) at util/header.c:137
        #2  0x00000000004eddba in write_bpf_prog_info (ff=0x7fffffff8f80, evlist=<optimized out>) at util/header.c:912
        #3  0x00000000004f69d7 in perf_event__synthesize_features (tool=tool@entry=0x97cc00 <record>, session=session@entry=0x7fffe9c6d010,
            evlist=0x7fffe9cae010, process=process@entry=0x4435d0 <process_synthesized_event>) at util/header.c:3695
        #4  0x0000000000443c79 in record__synthesize (tail=tail@entry=false, rec=0x97cc00 <record>) at builtin-record.c:1214
        #5  0x0000000000444ec9 in __cmd_record (rec=0x97cc00 <record>, argv=<optimized out>, argc=0) at builtin-record.c:1435
        #6  cmd_record (argc=0, argv=<optimized out>) at builtin-record.c:2450
        #7  0x00000000004ae3e9 in run_builtin (p=p@entry=0x98e058 <commands+216>, argc=argc@entry=3, argv=0x7fffffffd670) at perf.c:304
        #8  0x000000000042eded in handle_internal_command (argv=<optimized out>, argc=<optimized out>) at perf.c:356
        #9  run_argv (argcp=<optimized out>, argv=<optimized out>) at perf.c:400
        #10 main (argc=3, argv=<optimized out>) at perf.c:522
        (gdb)
      
      After the patch the SEGSEGV is gone.
      Reported-by: NDavid Carrillo Cisneros <davidca@fb.com>
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: kernel-team@fb.com
      Cc: stable@vger.kernel.org # v5.1+
      Fixes: 606f972b ("perf bpf: Save bpf_prog_info information as headers to perf.data")
      Link: http://lkml.kernel.org/r/20190620010453.4118689-1-songliubraving@fb.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c952b35f
  13. 02 7月, 2019 1 次提交
  14. 26 6月, 2019 2 次提交
  15. 25 6月, 2019 1 次提交
    • K
      perf tools: Increase MAX_NR_CPUS and MAX_CACHES · 9f94c7f9
      Kyle Meyer 提交于
      Attempting to profile 1024 or more CPUs with perf causes two errors:
      
        perf record -a
        [ perf record: Woken up X times to write data ]
        way too many cpu caches..
        [ perf record: Captured and wrote X MB perf.data (X samples) ]
      
        perf report -C 1024
        Error: failed to set  cpu bitmap
        Requested CPU 1024 too large. Consider raising MAX_NR_CPUS
      
        Increasing MAX_NR_CPUS from 1024 to 2048 and redefining MAX_CACHES as
        MAX_NR_CPUS * 4 returns normal functionality to perf:
      
        perf record -a
        [ perf record: Woken up X times to write data ]
        [ perf record: Captured and wrote X MB perf.data (X samples) ]
      
        perf report -C 1024
        ...
      Signed-off-by: NKyle Meyer <kyle.meyer@hpe.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20190620193630.154025-1-meyerk@stormcage.eag.rdlabs.hpecorp.netSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9f94c7f9
  16. 11 6月, 2019 2 次提交