1. 24 Jul, 2018 28 commits
    • Jiri Olsa's avatar
      perf tools: Use perf_evsel__match instead of open coded equivalent · 2d6cae13
      Jiri Olsa authored
      Use perf_evsel__match() helper in perf_evsel__is_bpf_output().
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180720110036.32251-1-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      2d6cae13
    • Jiri Olsa's avatar
      perf tools: Fix struct comm_str removal crash · 46b3722c
      Jiri Olsa authored
      We occasionaly hit following assert failure in 'perf top', when processing the
      /proc info in multiple threads.
      
        perf: ...include/linux/refcount.h:109: refcount_inc:
              Assertion `!(!refcount_inc_not_zero(r))' failed.
      
      The gdb backtrace looks like this:
      
        [Switching to Thread 0x7ffff11ba700 (LWP 13749)]
        0x00007ffff50839fb in raise () from /lib64/libc.so.6
        (gdb)
        #0  0x00007ffff50839fb in raise () from /lib64/libc.so.6
        #1  0x00007ffff5085800 in abort () from /lib64/libc.so.6
        #2  0x00007ffff507c0da in __assert_fail_base () from /lib64/libc.so.6
        #3  0x00007ffff507c152 in __assert_fail () from /lib64/libc.so.6
        #4  0x0000000000535373 in refcount_inc (r=0x7fffdc009be0)
            at ...include/linux/refcount.h:109
        #5  0x00000000005354f1 in comm_str__get (cs=0x7fffdc009bc0)
            at util/comm.c:24
        #6  0x00000000005356bd in __comm_str__findnew (str=0x7fffd000b260 ":2",
            root=0xbed5c0 <comm_str_root>) at util/comm.c:72
        #7  0x000000000053579e in comm_str__findnew (str=0x7fffd000b260 ":2",
            root=0xbed5c0 <comm_str_root>) at util/comm.c:95
        #8  0x000000000053582e in comm__new (str=0x7fffd000b260 ":2",
            timestamp=0, exec=false) at util/comm.c:111
        #9  0x00000000005363bc in thread__new (pid=2, tid=2) at util/thread.c:57
        #10 0x0000000000523da0 in ____machine__findnew_thread (machine=0xbfde38,
            threads=0xbfdf28, pid=2, tid=2, create=true) at util/machine.c:457
        #11 0x0000000000523eb4 in __machine__findnew_thread (machine=0xbfde38,
        ...
      
      The failing assertion is this one:
      
        REFCOUNT_WARN(!refcount_inc_not_zero(r), ...
      
      The problem is that we keep global comm_str_root list, which
      is accessed by multiple threads during the 'perf top' startup
      and following 2 paths can race:
      
        thread 1:
          ...
          thread__new
            comm__new
              comm_str__findnew
                down_write(&comm_str_lock);
                __comm_str__findnew
                  comm_str__get
      
        thread 2:
          ...
          comm__override or comm__free
            comm_str__put
              refcount_dec_and_test
                down_write(&comm_str_lock);
                rb_erase(&cs->rb_node, &comm_str_root);
      
      Because thread 2 first decrements the refcnt and only after then it removes the
      struct comm_str from the list, the thread 1 can find this object on the list
      with refcnt equls to 0 and hit the assert.
      
      This patch fixes the thread 1 __comm_str__findnew path, by ignoring objects
      that already dropped the refcnt to 0. For the rest of the objects we take the
      refcnt before comparing its name and release it afterwards with comm_str__put,
      which can also release the object completely.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Lukasz Odzioba <lukasz.odzioba@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: kernel-team@lge.com
      Link: http://lkml.kernel.org/r/20180720101740.GA27176@kravaSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      46b3722c
    • Jiri Olsa's avatar
      perf machine: Use last_match threads cache only in single thread mode · b57334b9
      Jiri Olsa authored
      There's an issue with using threads::last_match in multithread mode
      which is enabled during the perf top synthesize. It might crash with
      following assertion:
      
        perf: ...include/linux/refcount.h:109: refcount_inc:
              Assertion `!(!refcount_inc_not_zero(r))' failed.
      
      The gdb backtrace looks like this:
      
        0x00007ffff50839fb in raise () from /lib64/libc.so.6
        (gdb)
        #0  0x00007ffff50839fb in raise () from /lib64/libc.so.6
        #1  0x00007ffff5085800 in abort () from /lib64/libc.so.6
        #2  0x00007ffff507c0da in __assert_fail_base () from /lib64/libc.so.6
        #3  0x00007ffff507c152 in __assert_fail () from /lib64/libc.so.6
        #4  0x0000000000535ff9 in refcount_inc (r=0x7fffe8009a70)
            at ...include/linux/refcount.h:109
        #5  0x0000000000536771 in thread__get (thread=0x7fffe8009a40)
            at util/thread.c:115
        #6  0x0000000000523cd0 in ____machine__findnew_thread (machine=0xbfde38,
            threads=0xbfdf28, pid=2, tid=2, create=true) at util/machine.c:432
        #7  0x0000000000523eb4 in __machine__findnew_thread (machine=0xbfde38,
            pid=2, tid=2) at util/machine.c:489
        #8  0x0000000000523f24 in machine__findnew_thread (machine=0xbfde38,
            pid=2, tid=2) at util/machine.c:499
        #9  0x0000000000526fbe in machine__process_fork_event (machine=0xbfde38,
        ...
      
      The failing assertion is this one:
      
        REFCOUNT_WARN(!refcount_inc_not_zero(r), ...
      
      the problem is that we don't serialize access to threads::last_match.
      We serialize the access to the threads tree, but we don't care how's
      threads::last_match being accessed. Both locked/unlocked paths use
      that data and can set it. In multithreaded mode we can end up with
      invalid object in thread__get call, like in following paths race:
      
        thread 1
          ...
          machine__findnew_thread
            down_write(&threads->lock);
            __machine__findnew_thread
              ____machine__findnew_thread
                th = threads->last_match;
                if (th->tid == tid) {
                  thread__get
      
        thread 2
          ...
          machine__find_thread
            down_read(&threads->lock);
            __machine__findnew_thread
              ____machine__findnew_thread
                th = threads->last_match;
                if (th->tid == tid) {
                  thread__get
      
        thread 3
          ...
          machine__process_fork_event
            machine__remove_thread
              __machine__remove_thread
                threads->last_match = NULL
                thread__put
            thread__put
      
      Thread 1 and 2 might got stale last_match, before thread 3 clears
      it. Thread 1 and 2 then race with thread 3's thread__put and they
      might trigger the refcnt == 0 assertion above.
      
      The patch is disabling the last_match cache for multiple thread
      mode. It was originally meant for single thread scenarios, where
      it's common to have multiple sequential searches of the same
      thread.
      
      In multithread mode this does not make sense, because top's threads
      processes different /proc entries and so the 'struct threads' object
      is queried for various threads. Moreover we'd need to add more locks
      to make it work.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Lukasz Odzioba <lukasz.odzioba@intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/20180719143345.12963-4-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      b57334b9
    • Jiri Olsa's avatar
      perf machine: Add threads__set_last_match function · 67fda0f3
      Jiri Olsa authored
      Separating threads::last_match cache set into separate
      threads__set_last_match function.  This will be useful in following
      patch.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Lukasz Odzioba <lukasz.odzioba@intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/20180719143345.12963-3-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      67fda0f3
    • Jiri Olsa's avatar
      perf machine: Add threads__get_last_match function · f8b2ebb5
      Jiri Olsa authored
      Separating threads::last_match cache read/check into separate
      threads__get_last_match function. This will be useful in following
      patch.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Lukasz Odzioba <lukasz.odzioba@intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/20180719143345.12963-2-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      f8b2ebb5
    • Jiri Olsa's avatar
      perf tools: Synthesize GROUP_DESC feature in pipe mode · e8fedff1
      Jiri Olsa authored
      Stephan reported, that pipe mode does not carry the group information
      and thus the piped report won't display the grouped output for following
      command:
      
        # perf record -e '{cycles,instructions,branches}' -a sleep 4 | perf report
      
      It has no idea about the group setup, so it will display events
      separately:
      
        # Overhead  Command          Shared Object             ...
        # ........  ...............  .......................
        #
             6.71%  swapper          [kernel.kallsyms]
             2.28%  offlineimap      libpython2.7.so.1.0
             0.78%  perf             [kernel.kallsyms]
        ...
      
      Fix GROUP_DESC feature record to be synthesized in pipe mode, so the
      report output is grouped if there are groups defined in record:
      
        #                 Overhead  Command          Shared    ...
        # ........................  ...............  .......
        #
             7.57%   0.16%   0.30%  swapper          [kernel
             1.87%   3.15%   2.46%  offlineimap      libpyth
             1.33%   0.00%   0.00%  perf             [kernel
        ...
      Reported-by: default avatarStephane Eranian <eranian@google.com>
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Tested-by: default avatarStephane Eranian <eranian@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: David Carrillo-Cisneros <davidcc@google.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180712135202.14774-1-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      e8fedff1
    • Sandipan Das's avatar
      perf script: Show correct offsets for DWARF-based unwinding · 2a9d5050
      Sandipan Das authored
      When perf/data is recorded with the dwarf call-graph option, the
      callchain shown by 'perf script' still shows the binary offsets of the
      userspace symbols instead of their virtual addresses. Since the symbol
      offset calculation is based on using virtual address as the ip, we see
      incorrect offsets as well.
      
      The use of virtual addresses affects the ability to find out the
      line number in the corresponding source file to which an address
      maps to as described in commit 67540759 ("perf unwind: Use
      addr_location::addr instead of ip for entries").
      
      This has also been addressed by temporarily converting the virtual
      address to the correponding binary offset so that it can be mapped
      to the source line number correctly.
      
      This is a follow-up for commit 19610184 ("perf script: Show
      virtual addresses instead of offsets").
      
      This can be verified on a powerpc64le system running Fedora 27 as
      shown below:
      
        # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton
        # perf record -e probe_libc:inet_pton --call-graph=dwarf ping -6 -c 1 ::1
      
      Before:
      
        # perf report --stdio --no-children -s sym,srcline -g address
      
        # Samples: 1  of event 'probe_libc:inet_pton'
        # Event count (approx.): 1
        #
        # Overhead  Symbol                Source:Line
        # ........  ....................  ...........
        #
           100.00%  [.] __GI___inet_pton  inet_pton.c
                    |
                    ---gaih_inet getaddrinfo.c:537 (inlined)
                       __GI_getaddrinfo getaddrinfo.c:2304 (inlined)
                       main ping.c:519
                       generic_start_main libc-start.c:308 (inlined)
                       __libc_start_main libc-start.c:102
        ...
      
        # perf script -F comm,ip,sym,symoff,srcline,dso
      
        ping
                          15af28 __GI___inet_pton+0xffff000099160008 (/usr/lib64/libc-2.26.so)
          libc-2.26.so[ffff80004ca0af28]
                          10fa53 gaih_inet+0xffff000099160f43
          libc-2.26.so[ffff80004c9bfa53] (inlined)
                          1105b3 __GI_getaddrinfo+0xffff000099160163
          libc-2.26.so[ffff80004c9c05b3] (inlined)
                            2d6f main+0xfffffffd9f1003df (/usr/bin/ping)
          ping[fffffffecf882d6f]
                           2369f generic_start_main+0xffff00009916013f
          libc-2.26.so[ffff80004c8d369f] (inlined)
                           23897 __libc_start_main+0xffff0000991600b7 (/usr/lib64/libc-2.26.so)
          libc-2.26.so[ffff80004c8d3897]
      
      After:
      
        # perf report --stdio --no-children -s sym,srcline -g address
      
        # Samples: 1  of event 'probe_libc:inet_pton'
        # Event count (approx.): 1
        #
        # Overhead  Symbol                Source:Line
        # ........  ....................  ...........
        #
           100.00%  [.] __GI___inet_pton  inet_pton.c
                    |
                    ---gaih_inet.constprop.7 getaddrinfo.c:537
                       getaddrinfo getaddrinfo.c:2304
                       main ping.c:519
                       generic_start_main.isra.0 libc-start.c:308
                       __libc_start_main libc-start.c:102
        ...
      
        # perf script -F comm,ip,sym,symoff,srcline,dso
      
        ping
                    7fffb38aaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
          inet_pton.c:68
                    7fffb385fa53 gaih_inet.constprop.7+0xf43 (/usr/lib64/libc-2.26.so)
          getaddrinfo.c:537
                    7fffb38605b3 getaddrinfo+0x163 (/usr/lib64/libc-2.26.so)
          getaddrinfo.c:2304
                       130782d6f main+0x3df (/usr/bin/ping)
          ping.c:519
                    7fffb377369f generic_start_main.isra.0+0x13f (/usr/lib64/libc-2.26.so)
          libc-start.c:308
                    7fffb3773897 __libc_start_main+0xb7 (/usr/lib64/libc-2.26.so)
          libc-start.c:102
      Signed-off-by: default avatarSandipan Das <sandipan@linux.ibm.com>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Milian Wolff <milian.wolff@kdab.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Fixes: 67540759 ("perf unwind: Use addr_location::addr instead of ip for entries")
      Link: http://lkml.kernel.org/r/20180703120555.32971-1-sandipan@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      2a9d5050
    • Kim Phillips's avatar
      perf trace arm64: Use generated syscall table · a7f660d6
      Kim Phillips authored
      This should speed up accessing new system calls introduced with the
      kernel rather than waiting for libaudit updates to include them.
      
      It also enables users to specify wildcards, for example, perf trace -e
      'open*', just like was already possible on x86, s390, and powerpc, which
      means arm64 can now pass the "Check open filename arg using perf trace +
      vfs_getname" test.
      Signed-off-by: default avatarKim Phillips <kim.phillips@arm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/20180706163454.f714b9ab49ecc8566a0b3565@arm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      a7f660d6
    • Kim Phillips's avatar
      perf arm64: Generate system call table from asm/unistd.h · 2b588243
      Kim Phillips authored
      This should speed up accessing new system calls introduced with the
      kernel rather than waiting for libaudit updates to include them.
      
      Using the existing other arch scripts resulted in this error:
      
        tools/perf/arch/arm64/entry/syscalls//mksyscalltbl: 25: printf: __NR3264_ftruncate: expected numeric value
      
      because, unlike other arches, asm-generic's unistd.h does things like:
      
        #define __NR_ftruncate __NR3264_ftruncate
      
      Turning the scripts printf's %d into a %s resulted in this in the
      generated syscalls.c file:
      
          static const char *syscalltbl_arm64[] = {
                  [__NR3264_ftruncate] = "ftruncate",
      
      So we use the host C compiler to fold the macros, and print them out
      from within a temporary C program, in order to get the correct output:
      
          static const char *syscalltbl_arm64[] = {
                  [46] = "ftruncate",
      
      Committer notes:
      
      Testing this with a container with an old toolchain breaks because it
      ends up using the system's /usr/include/asm-generic/unistd.h, included
      from tools/arch/arm64/include/uapi/asm/unistd.h when what is desired is
      for it to include tools/include/uapi/asm-generic/unistd.h.
      
      Since all that tools/arch/arm64/include/uapi/asm/unistd.h is to set a
      define and then include asm-generic/unistd.h, do that directly and use
      tools/include/uapi/asm-generic/unistd.h as the file to get the syscall
      definitions to expand.
      
      Testing it:
      
         tools/perf/arch/arm64/entry/syscalls/mksyscalltbl /gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc gcc tools/include/uapi/asm-generic/unistd.h
      
      Now works and generates in the syscall string table.
      
      Before it ended up as:
      
        $ tools/perf/arch/arm64/entry/syscalls/mksyscalltbl /gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc gcc tools/arch/arm64/include/uapi/asm/unistd.h
        static const char *syscalltbl_arm64[] = {
        <stdin>: In function 'main':
        <stdin>:257:38: error: '__NR_getrandom' undeclared (first use in this function)
        <stdin>:257:38: note: each undeclared identifier is reported only once for each function it appears in
        <stdin>:258:41: error: '__NR_memfd_create' undeclared (first use in this function)
        <stdin>:259:32: error: '__NR_bpf' undeclared (first use in this function)
        <stdin>:260:37: error: '__NR_execveat' undeclared (first use in this function)
        tools/perf/arch/arm64/entry/syscalls/mksyscalltbl: 47: tools/perf/arch/arm64/entry/syscalls/mksyscalltbl: /tmp/create-table-60liya: Permission denied
        };
        $
      Signed-off-by: default avatarKim Phillips <kim.phillips@arm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/20180706163443.22626f5e9e10e5bab5e5c662@arm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      2b588243
    • Kim Phillips's avatar
      tools include: Grab copies of arm64 dependent unistd.h files · 34b009cf
      Kim Phillips authored
      Will be used for generating the syscall id/string translation table.
      
      The arm64 unistd.h file simply #includes the asm-generic/unistd.h, so,
      since we will want to know whether either change, we grab both:
      
        arch/arm64/include/uapi/asm/unistd.h
      
      and
      
        include/uapi/asm-generic/unistd.h
      Signed-off-by: default avatarKim Phillips <kim.phillips@arm.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/20180706163434.1b64ffbcc0284fb79982f53b@arm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      34b009cf
    • Sandipan Das's avatar
      perf tests: Fix record+probe_libc_inet_pton.sh when event exists · 60089e42
      Sandipan Das authored
      If the event 'probe_libc:inet_pton' already exists, this test fails and
      deletes the existing event before exiting. This will then pass for any
      subsequent executions.
      
      Instead of skipping to deleting the existing event because of failing to
      add a new event, a duplicate event is now created and the script
      continues with the usual checks. Only the new duplicate event that is
      created at the beginning of the test is deleted as a part of the
      cleanups in the end. All existing events remain as it is.
      
      This can be observed on a powerpc64 system running Fedora 27 as shown
      below.
      
        # perf probe -x /usr/lib64/power8/libc-2.26.so -a inet_pton
      
        Added new event:
          probe_libc:inet_pton (on inet_pton in /usr/lib64/power8/libc-2.26.so)
      
      Before:
      
        # perf test -v "probe libc's inet_pton & backtrace it with ping"
      
        62: probe libc's inet_pton & backtrace it with ping       :
        --- start ---
        test child forked, pid 21302
        test child finished with -1
        ---- end ----
        probe libc's inet_pton & backtrace it with ping: FAILED!
      
        # perf probe --list
      
      After:
      
        # perf test -v "probe libc's inet_pton & backtrace it with ping"
      
        62: probe libc's inet_pton & backtrace it with ping       :
        --- start ---
        test child forked, pid 21490
        ping 21513 [035] 39357.565561: probe_libc:inet_pton_1: (7fffa4c623b0)
        7fffa4c623b0 __GI___inet_pton+0x0 (/usr/lib64/power8/libc-2.26.so)
        7fffa4c190dc gaih_inet.constprop.7+0xf4c (/usr/lib64/power8/libc-2.26.so)
        7fffa4c19c4c getaddrinfo+0x15c (/usr/lib64/power8/libc-2.26.so)
        111d93c20 main+0x3e0 (/usr/bin/ping)
        test child finished with 0
        ---- end ----
        probe libc's inet_pton & backtrace it with ping: Ok
      
        # perf probe --list
      
          probe_libc:inet_pton (on __inet_pton@resolv/inet_pton.c in /usr/lib64/power8/libc-2.26.so)
      Signed-off-by: default avatarSandipan Das <sandipan@linux.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/e11fecff96e6cf4c65cdbd9012463513d7b8356c.1530724939.git.sandipan@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      60089e42
    • Sandipan Das's avatar
      perf tests: Fix record+probe_libc_inet_pton.sh to ensure cleanups · 83e3b6d7
      Sandipan Das authored
      If there is a mismatch in the perf script output, this test fails and
      exits before the event and temporary files created during its execution
      are cleaned up.
      
      This can be observed on a powerpc64 system running Fedora 27 as shown
      below.
      
        # perf test -v "probe libc's inet_pton & backtrace it with ping"
      
        62: probe libc's inet_pton & backtrace it with ping       :
        --- start ---
        test child forked, pid 18655
        ping 18674 [013] 24511.496995: probe_libc:inet_pton: (7fffa6b423b0)
        7fffa6b423b0 __GI___inet_pton+0x0 (/usr/lib64/power8/libc-2.26.so)
        7fffa6af90dc gaih_inet.constprop.7+0xf4c (/usr/lib64/power8/libc-2.26.so)
        FAIL: expected backtrace entry "getaddrinfo\+0x[[:xdigit:]]+[[:space:]]\(/usr/lib64/power8/libc-2.26.so\)$" got "7fffa6af90dc gaih_inet.constprop.7+0xf4c (/usr/lib64/power8/libc-2.26.so)"
        test child finished with -1
        ---- end ----
        probe libc's inet_pton & backtrace it with ping: FAILED!
      
        # ls /tmp/expected.* /tmp/perf.data.* /tmp/perf.script.*
      
        /tmp/expected.u31  /tmp/perf.data.Pki  /tmp/perf.script.Bhs
      
        # perf probe --list
      
          probe_libc:inet_pton (on __inet_pton@resolv/inet_pton.c in /usr/lib64/power8/libc-2.26.so)
      
      Cleanup of the event and the temporary files are now ensured by allowing
      the cleanup code to be executed even if the lines from the backtrace do
      not match their expected patterns instead of simply exiting from the
      point of failure.
      Signed-off-by: default avatarSandipan Das <sandipan@linux.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/ce9fb091dd3028fba8749a1a267cfbcb264bbfb1.1530724939.git.sandipan@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      83e3b6d7
    • Sandipan Das's avatar
      perf tests: Fix record+probe_libc_inet_pton.sh for powerpc64 · 3eae52f8
      Sandipan Das authored
      For powerpc64, this test currently fails due to a mismatch in the
      expected output.
      
      This can be observed on a powerpc64le system running Fedora 27 as shown
      below.
      
        # perf test -v "probe libc's inet_pton & backtrace it with ping"
      
      Before:
      
        62: probe libc's inet_pton & backtrace it with ping       :
        --- start ---
        test child forked, pid 23948
        ping 23965 [003] 71136.075084: probe_libc:inet_pton: (7fff996aaf28)
        7fff996aaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
        7fff9965fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
        FAIL: expected backtrace entry 2 "getaddrinfo\+0x[[:xdigit:]]+[[:space:]]\(/usr/lib64/libc-2.26.so\)$" got "7fff9965fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)"
        test child finished with -1
        ---- end ----
        probe libc's inet_pton & backtrace it with ping: FAILED!
      
      After:
      
        62: probe libc's inet_pton & backtrace it with ping       :
        --- start ---
        test child forked, pid 24638
        ping 24655 [001] 71208.525396: probe_libc:inet_pton: (7fffa245af28)
        7fffa245af28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
        7fffa240fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
        7fffa24105b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
        138d52d70 main+0x3e0 (/usr/bin/ping)
        test child finished with 0
        ---- end ----
        probe libc's inet_pton & backtrace it with ping: Ok
      Signed-off-by: default avatarSandipan Das <sandipan@linux.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Maynard Johnson <maynard@us.ibm.com>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Fixes: e07d585e2454 ("perf tests: Switch trace+probe_libc_inet_pton to use record")
      Link: http://lkml.kernel.org/r/49621ec5f37109f0655e5a8c32287ad68d85a1e5.1530724939.git.sandipan@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      3eae52f8
    • Sandipan Das's avatar
      perf powerpc: Fix callchain ip filtering when return address is in a register · 9068533e
      Sandipan Das authored
      For powerpc64, perf will filter out the second entry in the callchain,
      i.e. the LR value, if the return address of the function corresponding
      to the probed location has already been saved on its caller's stack.
      
      The state of the return address is determined using debug information.
      At any point within a function, if the return address is already saved
      somewhere, a DWARF expression can tell us about its location. If the
      return address in still in LR only, no DWARF expression would exist.
      
      Typically, the instructions in a function's prologue first copy the LR
      value to R0 and then pushes R0 on to the stack. If LR has already been
      copied to R0 but R0 is yet to be pushed to the stack, we can still get a
      DWARF expression that says that the return address is in R0. This is
      indicating that getting a DWARF expression for the return address does
      not guarantee the fact that it has already been saved on the stack.
      
      This can be observed on a powerpc64le system running Fedora 27 as shown
      below.
      
        # objdump -d /usr/lib64/libc-2.26.so | less
        ...
        000000000015af20 <inet_pton>:
          15af20:       0b 00 4c 3c     addis   r2,r12,11
          15af24:       e0 c1 42 38     addi    r2,r2,-15904
          15af28:       a6 02 08 7c     mflr    r0
          15af2c:       f0 ff c1 fb     std     r30,-16(r1)
          15af30:       f8 ff e1 fb     std     r31,-8(r1)
          15af34:       78 1b 7f 7c     mr      r31,r3
          15af38:       78 23 83 7c     mr      r3,r4
          15af3c:       78 2b be 7c     mr      r30,r5
          15af40:       10 00 01 f8     std     r0,16(r1)
          15af44:       c1 ff 21 f8     stdu    r1,-64(r1)
          15af48:       28 00 81 f8     std     r4,40(r1)
        ...
      
        # readelf --debug-dump=frames-interp /usr/lib64/libc-2.26.so | less
        ...
        00027024 0000000000000024 00027028 FDE cie=00000000 pc=000000000015af20..000000000015af88
           LOC           CFA      r30   r31   ra
        000000000015af20 r1+0     u     u     u
        000000000015af34 r1+0     c-16  c-8   r0
        000000000015af48 r1+64    c-16  c-8   c+16
        000000000015af5c r1+0     c-16  c-8   c+16
        000000000015af78 r1+0     u     u
        ...
      
        # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x18
        # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
        # perf script
      
      Before:
      
        ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
                    7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
                    7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
                       12f152d70 _init+0xbfc (/usr/bin/ping)
                    7fff7e1836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
                    7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                               0 [unknown] ([unknown])
      
      After:
      
        ping  2829 [005] 512917.460174: probe_libc:inet_pton: (7fff7e2baf38)
                    7fff7e2baf38 __GI___inet_pton+0x18 (/usr/lib64/libc-2.26.so)
                    7fff7e26fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
                    7fff7e2705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
                       12f152d70 _init+0xbfc (/usr/bin/ping)
                    7fff7e1836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
                    7fff7e183898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                               0 [unknown] ([unknown])
      Reported-by: default avatarRavi Bangoria <ravi.bangoria@linux.ibm.com>
      Signed-off-by: default avatarSandipan Das <sandipan@linux.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Maynard Johnson <maynard@us.ibm.com>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/66e848a7bdf2d43b39210a705ff6d828a0865661.1530724939.git.sandipan@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      9068533e
    • Sandipan Das's avatar
      perf powerpc: Fix callchain ip filtering · c715fcfd
      Sandipan Das authored
      For powerpc64, redundant entries in the callchain are filtered out by
      determining the state of the return address and the stack frame using
      DWARF debug information.
      
      For making these filtering decisions we must analyze the debug
      information for the location corresponding to the program counter value,
      i.e. the first entry in the callchain, and not the LR value; otherwise,
      perf may filter out either the second or the third entry in the
      callchain incorrectly.
      
      This can be observed on a powerpc64le system running Fedora 27 as shown
      below.
      
      Case 1 - Attaching a probe at inet_pton+0x8 (binary offset 0x15af28).
               Return address is still in LR and a new stack frame is not yet
               allocated. The LR value, i.e. the second entry, should not be
      	 filtered out.
      
        # objdump -d /usr/lib64/libc-2.26.so | less
        ...
        000000000010eb10 <gaih_inet.constprop.7>:
        ...
          10fa48:       78 bb e4 7e     mr      r4,r23
          10fa4c:       0a 00 60 38     li      r3,10
          10fa50:       d9 b4 04 48     bl      15af28 <inet_pton+0x8>
          10fa54:       00 00 00 60     nop
          10fa58:       ac f4 ff 4b     b       10ef04 <gaih_inet.constprop.7+0x3f4>
        ...
        0000000000110450 <getaddrinfo>:
        ...
          1105a8:       54 00 ff 38     addi    r7,r31,84
          1105ac:       58 00 df 38     addi    r6,r31,88
          1105b0:       69 e5 ff 4b     bl      10eb18 <gaih_inet.constprop.7+0x8>
          1105b4:       78 1b 71 7c     mr      r17,r3
          1105b8:       50 01 7f e8     ld      r3,336(r31)
        ...
        000000000015af20 <inet_pton>:
          15af20:       0b 00 4c 3c     addis   r2,r12,11
          15af24:       e0 c1 42 38     addi    r2,r2,-15904
          15af28:       a6 02 08 7c     mflr    r0
          15af2c:       f0 ff c1 fb     std     r30,-16(r1)
          15af30:       f8 ff e1 fb     std     r31,-8(r1)
        ...
      
        # perf probe -x /usr/lib64/libc-2.26.so -a inet_pton+0x8
        # perf record -e probe_libc:inet_pton -g ping -6 -c 1 ::1
        # perf script
      
      Before:
      
        ping  4507 [002] 514985.546540: probe_libc:inet_pton: (7fffa7dbaf28)
                    7fffa7dbaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
                    7fffa7d705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
                       13fb52d70 _init+0xbfc (/usr/bin/ping)
                    7fffa7c836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
                    7fffa7c83898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                               0 [unknown] ([unknown])
      
      After:
      
        ping  4507 [002] 514985.546540: probe_libc:inet_pton: (7fffa7dbaf28)
                    7fffa7dbaf28 __GI___inet_pton+0x8 (/usr/lib64/libc-2.26.so)
                    7fffa7d6fa54 gaih_inet.constprop.7+0xf44 (/usr/lib64/libc-2.26.so)
                    7fffa7d705b4 getaddrinfo+0x164 (/usr/lib64/libc-2.26.so)
                       13fb52d70 _init+0xbfc (/usr/bin/ping)
                    7fffa7c836a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
                    7fffa7c83898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                               0 [unknown] ([unknown])
      
      Case 2 - Attaching a probe at _int_malloc+0x180 (binary offset 0x9cf10).
               Return address in still in LR and a new stack frame has already
               been allocated but not used. The caller's caller, i.e. the third
      	 entry, is invalid and should be filtered out and not the second
      	 one.
      
        # objdump -d /usr/lib64/libc-2.26.so | less
        ...
        000000000009cd90 <_int_malloc>:
           9cd90:       17 00 4c 3c     addis   r2,r12,23
           9cd94:       70 a3 42 38     addi    r2,r2,-23696
           9cd98:       26 00 80 7d     mfcr    r12
           9cd9c:       f8 ff e1 fb     std     r31,-8(r1)
           9cda0:       17 00 e4 3b     addi    r31,r4,23
           9cda4:       d8 ff 61 fb     std     r27,-40(r1)
           9cda8:       78 23 9b 7c     mr      r27,r4
           9cdac:       1f 00 bf 2b     cmpldi  cr7,r31,31
           9cdb0:       f0 ff c1 fb     std     r30,-16(r1)
           9cdb4:       b0 ff c1 fa     std     r22,-80(r1)
           9cdb8:       78 1b 7e 7c     mr      r30,r3
           9cdbc:       08 00 81 91     stw     r12,8(r1)
           9cdc0:       11 ff 21 f8     stdu    r1,-240(r1)
           9cdc4:       4c 01 9d 41     bgt     cr7,9cf10 <_int_malloc+0x180>
           9cdc8:       20 00 a4 2b     cmpldi  cr7,r4,32
        ...
           9cf08:       00 00 00 60     nop
           9cf0c:       00 00 42 60     ori     r2,r2,0
           9cf10:       e4 06 ff 7b     rldicr  r31,r31,0,59
           9cf14:       40 f8 a4 7f     cmpld   cr7,r4,r31
           9cf18:       68 05 9d 41     bgt     cr7,9d480 <_int_malloc+0x6f0>
        ...
        000000000009e3c0 <tcache_init.part.4>:
        ...
           9e420:       40 02 80 38     li      r4,576
           9e424:       78 fb e3 7f     mr      r3,r31
           9e428:       71 e9 ff 4b     bl      9cd98 <_int_malloc+0x8>
           9e42c:       00 00 a3 2f     cmpdi   cr7,r3,0
           9e430:       78 1b 7e 7c     mr      r30,r3
        ...
        000000000009f7a0 <__libc_malloc>:
        ...
           9f8f8:       00 00 89 2f     cmpwi   cr7,r9,0
           9f8fc:       1c ff 9e 40     bne     cr7,9f818 <__libc_malloc+0x78>
           9f900:       c9 ea ff 4b     bl      9e3c8 <tcache_init.part.4+0x8>
           9f904:       00 00 00 60     nop
           9f908:       e8 90 22 e9     ld      r9,-28440(r2)
        ...
      
        # perf probe -x /usr/lib64/libc-2.26.so -a _int_malloc+0x180
        # perf record -e probe_libc:_int_malloc -g ./test-malloc
        # perf script
      
      Before:
      
        test-malloc  6554 [009] 515975.797403: probe_libc:_int_malloc: (7fffa6e6cf10)
                    7fffa6e6cf10 _int_malloc+0x180 (/usr/lib64/libc-2.26.so)
                    7fffa6dd0000 [unknown] (/usr/lib64/libc-2.26.so)
                    7fffa6e6f904 malloc+0x164 (/usr/lib64/libc-2.26.so)
                    7fffa6e6f9fc malloc+0x25c (/usr/lib64/libc-2.26.so)
                        100006b4 main+0x38 (/home/testuser/test-malloc)
                    7fffa6df36a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
                    7fffa6df3898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                               0 [unknown] ([unknown])
      
      After:
      
        test-malloc  6554 [009] 515975.797403: probe_libc:_int_malloc: (7fffa6e6cf10)
                    7fffa6e6cf10 _int_malloc+0x180 (/usr/lib64/libc-2.26.so)
                    7fffa6e6e42c tcache_init.part.4+0x6c (/usr/lib64/libc-2.26.so)
                    7fffa6e6f904 malloc+0x164 (/usr/lib64/libc-2.26.so)
                    7fffa6e6f9fc malloc+0x25c (/usr/lib64/libc-2.26.so)
                        100006b4 main+0x38 (/home/sandipan/test-malloc)
                    7fffa6df36a0 generic_start_main.isra.0+0x140 (/usr/lib64/libc-2.26.so)
                    7fffa6df3898 __libc_start_main+0xb8 (/usr/lib64/libc-2.26.so)
                               0 [unknown] ([unknown])
      Signed-off-by: default avatarSandipan Das <sandipan@linux.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Maynard Johnson <maynard@us.ibm.com>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Fixes: a60335ba ("perf tools powerpc: Adjust callchain based on DWARF debug info")
      Link: http://lkml.kernel.org/r/24bb726d91ed173aebc972ec3f41a2ef2249434e.1530724939.git.sandipan@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      c715fcfd
    • Sangwon Hong's avatar
      perf list: Add missing documentation for --desc and --debug options · 6feb3fec
      Sangwon Hong authored
      Add missing documentation for --desc and --debug options to the 'perf
      list' man page.
      Signed-off-by: default avatarSangwon Hong <qpakzk@gmail.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/20180717110738.10779-1-qpakzk@gmail.com
      [ Clarify that --desc is by default active ]
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      6feb3fec
    • Thomas Richter's avatar
      perf kvm: Fix subcommands on s390 · 8a95c899
      Thomas Richter authored
      With commit eca0fa28 ("perf record: Provide detailed information on
      s390 CPU") s390 platform provides detailed type/model/capacity
      information in the CPU identifier string instead of just "IBM/S390".
      
      This breaks 'perf kvm' support which uses hard coded string IBM/S390 to
      compare with the CPU identifier string. Fix this by changing the
      comparison.
      Reported-by: default avatarStefan Raspl <raspl@linux.ibm.com>
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Tested-by: default avatarStefan Raspl <raspl@linux.ibm.com>
      Acked-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: stable@vger.kernel.org
      Fixes: eca0fa28 ("perf record: Provide detailed information on s390 CPU")
      Link: http://lkml.kernel.org/r/20180712070936.67547-1-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      8a95c899
    • Thomas Richter's avatar
      perf stat: Add transaction flag (-T) support for s390 · 742d92ff
      Thomas Richter authored
      The 'perf stat' command line flag -T to display transaction counters is
      currently supported for x86 only.
      
      Add support for s390. It is based on the metrics flag -M transaction
      using the architecture dependent JSON files. This requires a metric
      named "transaction" in the JSON files for the platform.
      
      Introduce a new function metricgroup__has_metric() to check for the
      existence of a metric_name transaction.
      
      As suggested by Andi Kleen, this is the new approach to support
      transactions counters. Other architectures will follow.
      
      Output before:
      
        [root@p23lp27 perf]# ./perf stat -T -- sleep 1
        Cannot set up transaction events
        [root@p23lp27 perf]#
      
      Output after:
      
        [root@s35lp76 perf]# ./perf stat -T -- ~/mytesttx 1 >/tmp/111
      
         Performance counter stats for '/root/mytesttx 1':
      
                         1      tx_c_tend           #     13.0 transaction
                         1      tx_nc_tend
                        11      tx_nc_tabort
                         0      tx_c_tabort_special
                         0      tx_c_tabort_no_special
      
               0.001070109 seconds time elapsed
      
        [root@s35lp76 perf]#
      Suggested-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Acked-by: default avatarAndi Kleen <ak@linux.intel.com>
      Acked-by: default avatarJiri Olsa <jolsa@redhat.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Link: http://lkml.kernel.org/r/20180626071701.58190-1-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      742d92ff
    • Thomas Richter's avatar
      perf json: Add s390 transaction counter definition · 83eb383e
      Thomas Richter authored
      'perf stat' displays transactional counters using flag -T on x86.  On
      s390 use a JSON file defined metric named transaction to achieve the
      same result.
      
      Output before:
      
        none
      
      Output after:
      
        [root@s35lp76 perf]# ./perf stat -M transaction  -- \
      			  ~/mytesttx 1 >/tmp/111
      
         Performance counter stats for '/root/mytesttx 1':
      
                         1      tx_c_tend           #     13.0 transaction
                         1      tx_nc_tend
                        11      tx_nc_tabort
                         0      tx_c_tabort_special
                         0      tx_c_tabort_no_special
      
               0.001061232 seconds time elapsed
      
        [root@s35lp76 perf]#
      Suggested-by: default avatarAndi Kleen <ak@linux.intel.com>
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Link: http://lkml.kernel.org/r/20180621080452.61012-3-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      83eb383e
    • Thomas Richter's avatar
      perf list: Add s390 support for detailed PMU event description · 9bacbced
      Thomas Richter authored
      Correct the support of detailed/verbose PMU event description by using
      the "Unit": keyword in the json files to address event names refering to
      the /sys/devices/cpum_[cs]f devices.
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Link: http://lkml.kernel.org/r/20180621080452.61012-2-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      9bacbced
    • Thomas Richter's avatar
      Revert "perf list: Add s390 support for detailed/verbose PMU event description" · b8b5ab52
      Thomas Richter authored
      This reverts commit 038586c3.
      
      Fix the support of detailed/verbose PMU event description by using the
      "Unit": keyword in the json files to address event names refering to the
      /sys/devices/cpum_[cs]f devices.
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Link: http://lkml.kernel.org/r/20180621080452.61012-1-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      b8b5ab52
    • Leo Yan's avatar
      perf cs-etm: Bail out immediately for instruction sample failure · 6cd4ac6a
      Leo Yan authored
      If the instruction sample failure has happened, it isn't necessary to
      execute to the end of the function cs_etm__flush().  This commit is to
      bail out immediately and return the error code.
      Signed-off-by: default avatarLeo Yan <leo.yan@linaro.org>
      Reviewed-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Mike Leach <mike.leach@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Walker <robert.walker@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/1529298599-3876-3-git-send-email-leo.yan@linaro.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      6cd4ac6a
    • Leo Yan's avatar
      perf cs-etm: Introduce invalid address macro · 6abf0f45
      Leo Yan authored
      This patch introduces invalid address macro and uses it to replace dummy
      value '0xdeadbeefdeadbeefUL'.
      Signed-off-by: default avatarLeo Yan <leo.yan@linaro.org>
      Reviewed-by: default avatarMathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Mike Leach <mike.leach@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Walker <robert.walker@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/1529298599-3876-2-git-send-email-leo.yan@linaro.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      6abf0f45
    • Arnaldo Carvalho de Melo's avatar
      perf hists: Clarify callchain disabling when available · e9de7e2f
      Arnaldo Carvalho de Melo authored
      We want to allow having mixed events with/without callchains, not
      using a global flag to show callchains, but allowing supressing
      callchains when they are present.
      
      So invert the logic of the last parameter to hists__fprint() to
      that effect.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-ohqyisr6qge79qa95ojslptx@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      e9de7e2f
    • Alexey Budankov's avatar
      perf tests: Check that complex event name is parsed correctly · 06dc5bf2
      Alexey Budankov authored
      Extend regression testing to cover case of complex event names enabled
      by the cset f92da712 ("perf record: Enable arbitrary event names
      thru name= modifier").
      
      Testing it:
      
        # perf test
         1: vmlinux symtab matches kallsyms                       : Skip
         2: Detect openat syscall event                           : Ok
         3: Detect openat syscall event on all cpus               : Ok
         4: Read samples using the mmap interface                 : Ok
         5: Test data source output                               : Ok
         6: Parse event definition strings                        : Ok		<===!
         7: Simple expression parser                              : Ok
      ...
      
      Committer testing:
      
        # perf test "event definition"
         6: Parse event definition strings                        : Ok
        # perf test -v 6 2> /tmp/before
        # perf test -v 6 2> /tmp/after
        # diff -u /tmp/before /tmp/after
        --- /tmp/before	2018-06-19 10:50:21.485572638 -0300
        +++ /tmp/after	2018-06-19 10:50:40.886572896 -0300
        @@ -1,6 +1,6 @@
          6: Parse event definition strings                        :
         --- start ---
        -test child forked, pid 24259
        +test child forked, pid 24904
         running test 0 'syscalls:sys_enter_openat'Using CPUID GenuineIntel-6-3D
         registering plugin: /root/.traceevent/plugins/plugin_kvm.so
         registering plugin: /root/.traceevent/plugins/plugin_hrtimer.so
        @@ -136,9 +136,11 @@
         running test 50 '4:0x6530160/name=numpmu/'
         running test 51 'L1-dcache-misses/name=cachepmu/'
         running test 52 'intel_pt//u'
        +running test 53 'cycles/name='COMPLEX_CYCLES_NAME:orig=cycles,desc=chip-clock-ticks'/Duk'
         running test 0 'cpu/config=10,config1,config2=3,period=1000/u'
         running test 1 'cpu/config=1,name=krava/u,cpu/config=2/u'
         running test 2 'cpu/config=1,call-graph=fp,time,period=100000/,cpu/config=2,call-graph=no,time=0,period=2000/'
        +running test 3 'cpu/name='COMPLEX_CYCLES_NAME:orig=cycles,desc=chip-clock-ticks',period=0x1,event=0x2,umask=0x3/ukp'
         el-capacity -> cpu/event=0x54,umask=0x2/
         el-conflict -> cpu/event=0x54,umask=0x1/
         el-start -> cpu/event=0xc8,umask=0x1/
        #
      Signed-off-by: default avatarAlexey Budankov <alexey.budankov@linux.intel.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@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/ad30b774-219b-7b80-c610-4e9e298cf8a7@linux.intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      06dc5bf2
    • Arnaldo Carvalho de Melo's avatar
      1d59d16e
    • Ananth N Mavinakayanahalli's avatar
      MAINTAINERS: Add Naveen N. Rao as kprobes co-maintainer · 4799f685
      Ananth N Mavinakayanahalli authored
      Naveen has been contributing consistently reviewing and hardening
      kprobes for some time now. I have not been able to do the same due
      to other commitments.
      Signed-off-by: default avatarAnanth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: akpm@linux-foundation.org
      Cc: mhiramat@kernel.org
      Link: http://lkml.kernel.org/r/153180735790.1914.15547706781664285286.stgit@thinktuxSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4799f685
    • Thomas Gleixner's avatar
      perf/x86/amd/ibs: Don't access non-started event · d2753e6b
      Thomas Gleixner authored
      Paul Menzel reported the following bug:
      
      > Enabling the undefined behavior sanitizer and building GNU/Linux 4.18-rc5+
      > (with some unrelated commits) with GCC 8.1.0 from Debian Sid/unstable, the
      > warning below is shown.
      >
      > > [    2.111913]
      > > ================================================================================
      > > [    2.111917] UBSAN: Undefined behaviour in arch/x86/events/amd/ibs.c:582:24
      > > [    2.111919] member access within null pointer of type 'struct perf_event'
      > > [    2.111926] CPU: 0 PID: 144 Comm: udevadm Not tainted 4.18.0-rc5-00316-g4864b68cedf2 #104
      > > [    2.111928] Hardware name: ASROCK E350M1/E350M1, BIOS TIMELESS 01/01/1970
      > > [    2.111930] Call Trace:
      > > [    2.111943]  dump_stack+0x55/0x89
      > > [    2.111949]  ubsan_epilogue+0xb/0x33
      > > [    2.111953]  handle_null_ptr_deref+0x7f/0x90
      > > [    2.111958]  __ubsan_handle_type_mismatch_v1+0x55/0x60
      > > [    2.111964]  perf_ibs_handle_irq+0x596/0x620
      
      The code dereferences event before checking the STARTED bit. Patch
      below should cure the issue.
      
      The warning should not trigger, if I analyzed the thing correctly.
      (And Paul's testing confirms this.)
      Reported-by: default avatarPaul Menzel <pmenzel@molgen.mpg.de>
      Tested-by: default avatarPaul Menzel <pmenzel@molgen.mpg.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Menzel <pmenzel+linux-x86@molgen.mpg.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1807200958390.1580@nanos.tec.linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d2753e6b
  2. 22 Jul, 2018 8 commits
  3. 21 Jul, 2018 4 commits