1. 26 Sep, 2018 15 commits
    • John Stultz's avatar
      selftest: timers: Tweak raw_skew to SKIP when ADJ_OFFSET/other clock adjustments are in progress · 6c9e72d6
      John Stultz authored
      [ Upstream commit 1416270f ]
      
      In the past we've warned when ADJ_OFFSET was in progress, usually
      caused by ntpd or some other time adjusting daemon running in non
      steady sate, which can cause the skew calculations to be
      incorrect.
      
      Thus, this patch checks to see if the clock was being adjusted
      when we fail so that we don't cause false negatives.
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Miroslav Lichvar <mlichvar@redhat.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Prarit Bhargava <prarit@redhat.com>
      Cc: Stephen Boyd <sboyd@kernel.org>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: linux-kselftest@vger.kernel.org
      Suggested-by: default avatarMiroslav Lichvar <mlichvar@redhat.com>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c9e72d6
    • Li Zhijian's avatar
      selftests/android: initialize heap_type to avoid compiling warning · 0fce3c91
      Li Zhijian authored
      [ Upstream commit cc7c6730 ]
      
      Initialize heap_type to ION_HEAP_TYPE_SYSTEM to avoid "used uninitialized"
      compiler warning. heap_type gets used after initialization, this change is
      to just keep the compiler happy.
      
      root@vm-lkp-nex04-8G-7 ~/linux-v4.18-rc2/tools/testing/selftests/android# make
      make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
      make[1]: Entering directory '/root/linux-v4.18-rc2/tools/testing/selftests/android/ion'
      gcc  -I. -I../../../../../drivers/staging/android/uapi/ -I../../../../../usr/include/ -Wall -O2 -g    ionapp_export.c ipcsocket.c ionutils.c   -o ionapp_export
      ionapp_export.c: In function 'main':
      ionapp_export.c:91:2: warning: 'heap_type' may be used uninitialized in
      this function [-Wmaybe-uninitialized]
        printf("heap_type: %ld, heap_size: %ld\n", heap_type, heap_size);
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      CC: Shuah Khan <shuah@kernel.org>
      CC: Pintu Agarwal <pintu.ping@gmail.com>
      Signed-off-by: default avatarLi Zhijian <lizhijian@cn.fujitsu.com>
      Signed-off-by: default avatarShuah Khan (Samsung OSG) <shuah@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0fce3c91
    • Shuah Khan (Samsung OSG)'s avatar
      selftests: vDSO - fix to return KSFT_SKIP when test couldn't be run · 330e11b0
      Shuah Khan (Samsung OSG) authored
      [ Upstream commit d2d49495 ]
      
      Fix to return KSFT_SKIP when test couldn't be run because AT_SYSINFO_EHDR
      isn't found and gettimeofday isn't defined.
      Signed-off-by: default avatarShuah Khan (Samsung OSG) <shuah@kernel.org>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      330e11b0
    • Dan Williams's avatar
      tools/testing/nvdimm: Fix support for emulating controller temperature · 67a281a8
      Dan Williams authored
      [ Upstream commit e5d772fb ]
      
      In addition to populating the value the payload also needs to set the
      "controller temperature valid" flag.
      
      Fixes: cdd77d3e ("nfit, libnvdimm: deprecate the generic SMART ioctl")
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67a281a8
    • Adrian Hunter's avatar
      perf tools: Fix maps__find_symbol_by_name() · 1f3cb060
      Adrian Hunter authored
      commit 03db8b58 upstream.
      
      Commit 1c5aae77 ("perf machine: Create maps for x86 PTI entry
      trampolines") revealed a problem with maps__find_symbol_by_name() that
      resulted in probes not being found e.g.
      
      	$ sudo perf probe xsk_mmap
      	xsk_mmap is out of .text, skip it.
      	Probe point 'xsk_mmap' not found.
      	   Error: Failed to add events.
      
      maps__find_symbol_by_name() can optionally return the map of the found
      symbol. It can get the map wrong because, in fact, the symbol is found
      on the map's dso, not allowing for the possibility that the dso has more
      than one map. Fix by always checking the map contains the symbol.
      Reported-by: default avatarBjörn Töpel <bjorn.topel@intel.com>
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: default avatarBjörn Töpel <bjorn.topel@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: 1c5aae77 ("perf machine: Create maps for x86 PTI entry trampolines")
      Link: http://lkml.kernel.org/r/20180907085116.25782-1-adrian.hunter@intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f3cb060
    • K. Y. Srinivasan's avatar
      Tools: hv: Fix a bug in the key delete code · 662b1033
      K. Y. Srinivasan authored
      commit 86503bd3 upstream.
      
      Fix a bug in the key delete code - the num_records range
      from 0 to num_records-1.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Reported-by: default avatarDavid Binderman <dcb314@hotmail.com>
      Cc: <stable@vger.kernel.org>
      Reviewed-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      662b1033
    • Sandipan Das's avatar
      perf script: Show correct offsets for DWARF-based unwinding · acd8e750
      Sandipan Das authored
      [ Upstream commit 2a9d5050 ]
      
      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>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      acd8e750
    • Sandipan Das's avatar
      perf powerpc: Fix callchain ip filtering · b42c221e
      Sandipan Das authored
      [ Upstream commit c715fcfd ]
      
      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>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b42c221e
    • Sandipan Das's avatar
      perf powerpc: Fix callchain ip filtering when return address is in a register · 0c664f04
      Sandipan Das authored
      [ Upstream commit 9068533e ]
      
      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>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c664f04
    • Jiri Olsa's avatar
      perf tools: Fix struct comm_str removal crash · 6619761e
      Jiri Olsa authored
      [ Upstream commit 46b3722c ]
      
      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>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6619761e
    • Sandipan Das's avatar
      perf tests: Fix record+probe_libc_inet_pton.sh to ensure cleanups · 3340ab97
      Sandipan Das authored
      [ Upstream commit 83e3b6d7 ]
      
      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>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3340ab97
    • Sandipan Das's avatar
      perf tests: Fix record+probe_libc_inet_pton.sh when event exists · a036a426
      Sandipan Das authored
      [ Upstream commit 60089e42 ]
      
      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>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a036a426
    • Sandipan Das's avatar
      perf tests: Fix record+probe_libc_inet_pton.sh for powerpc64 · 79096332
      Sandipan Das authored
      [ Upstream commit 3eae52f8 ]
      
      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>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      79096332
    • Jiri Olsa's avatar
      perf tools: Synthesize GROUP_DESC feature in pipe mode · aee426d1
      Jiri Olsa authored
      [ Upstream commit e8fedff1 ]
      
      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>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aee426d1
    • Thomas Richter's avatar
      perf test: Fix subtest number when showing results · 4d63cecf
      Thomas Richter authored
      [ Upstream commit 9ef01124 ]
      
      Perf test 40 for example has several subtests numbered 1-4 when
      displaying the start of the subtest. When the subtest results
      are displayed the subtests are numbered 0-3.
      
      Use this command to generate trace output:
      
        [root@s35lp76 perf]# ./perf test -Fv 40 2>/tmp/bpf1
      
      Fix this by adjusting the subtest number when show the
      subtest result.
      
      Output before:
      
        [root@s35lp76 perf]# egrep '(^40\.[0-4]| subtest [0-4]:)' /tmp/bpf1
        40.1: Basic BPF filtering                                 :
        BPF filter subtest 0: Ok
        40.2: BPF pinning                                         :
        BPF filter subtest 1: Ok
        40.3: BPF prologue generation                             :
        BPF filter subtest 2: Ok
        40.4: BPF relocation checker                              :
        BPF filter subtest 3: Ok
        [root@s35lp76 perf]#
      
      Output after:
      
        root@s35lp76 ~]# egrep '(^40\.[0-4]| subtest [0-4]:)' /tmp/bpf1
        40.1: Basic BPF filtering                                 :
        BPF filter subtest 1: Ok
        40.2: BPF pinning                                         :
        BPF filter subtest 2: Ok
        40.3: BPF prologue generation                             :
        BPF filter subtest 3: Ok
        40.4: BPF relocation checker                              :
        BPF filter subtest 4: Ok
        [root@s35lp76 ~]#
      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/20180724134858.100644-1-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d63cecf
  2. 19 Sep, 2018 8 commits
    • Huaisheng Ye's avatar
      tools/testing/nvdimm: kaddr and pfn can be NULL to ->direct_access() · 0bf7bf99
      Huaisheng Ye authored
      [ Upstream commit 45df5d3d ]
      
      The mock / test version of pmem_direct_access() needs to check the
      validity of pointers kaddr and pfn for NULL assignment. If anyone
      equals to NULL, it doesn't need to calculate the value.
      
      If pointer equals to NULL, that is to say callers may have no need for
      kaddr or pfn, so this patch is prepared for allowing them to pass in
      NULL instead of having to pass in a local pointer or variable that
      they then just throw away.
      Suggested-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarHuaisheng Ye <yehs1@lenovo.com>
      Reviewed-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: default avatarDave Jiang <dave.jiang@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0bf7bf99
    • Thomas Richter's avatar
      perf build: Fix installation directory for eBPF · 1e83b3b9
      Thomas Richter authored
      [ Upstream commit 83868bf7 ]
      
      The perf tool build and install is controlled via a Makefile. The
      'install' rule creates directories and copies files. Among them are
      header files installed in /usr/lib/include/perf/bpf/.
      
      However all listed examples are installing its header files in
      
        /usr/lib/<tool-name>/...[/include]/header.h
      
      and not in
      
        /usr/lib/include/<tool-name>/.../header.h.
      
      Background information:
      
      Building the Fedora 28 glibc RPM on s390x and s390 fails on s390 (gcc
      -m31) as gcc is not able to find header-files like stdbool.h.
      
      In the glibc.spec file, you can see that glibc is configured with
      "--with-headers". In this case, first -nostdinc is added to the CFLAGS
      and then further include paths are added via -isystem.  One of those
      paths should contain header files like stdbool.h.
      
      In order to get this path, gcc is invoked with:
      
      - on Fedora 28 (with 4.18 kernel):
      
        $ gcc -print-file-name=include
        /usr/lib/gcc/s390x-redhat-linux/8/include
        $ gcc -m31 -print-file-name=include
        /usr/lib/gcc/s390x-redhat-linux/8/../../../../lib/include
        => If perf is installed, this is: /usr/lib/include
        On my machine this directory is only containing the directory "perf".
        If perf is not installed gcc returns: /usr/lib/gcc/s390x-redhat-linux/8/include
      
      - on Ubuntu 18.04 (with 4.15 kernel):
      
        $ gcc  -print-file-name=include
        /usr/lib/gcc/s390x-linux-gnu/7/include
        $ gcc -m31 -print-file-name=include
        /usr/lib/gcc/s390x-linux-gnu/7/include
        => gcc returns the correct path even if perf is installed.
      
      In each case, the introduction of the subdirectory /usr/lib/include
      leads to the regression that one can not build the glibc RPM for s390
      anymore as gcc can not find headers like stdbool.h.
      
      To remedy this install bpf.h to /usr/lib/perf/include/bpf/bpf.h
      
      Output before using the command 'perf test -Fv 40':
      
        echo '...[bpf-program-source]...' | /usr/bin/clang ... \
      		   -I/root/lib/include/perf/bpf ...
                                     ^^^^^^^^^^^^
      ...
        [root@p23lp27 perf]# perf test -F 40
        40: BPF filter                                            :
        40.1: Basic BPF filtering                                 : Ok
        40.2: BPF pinning                                         : Ok
        40.3: BPF prologue generation                             : Ok
        40.4: BPF relocation checker                              : Ok
        [root@p23lp27 perf]#
      
      Output after using command 'perf test -Fv 40':
      
        echo '...[bpf-program-source]...' | /usr/bin/clang ... \
      		 -I/root/lib/perf/include/bpf ...
                                   ^^^^^^^^^^^^
      ...
        [root@p23lp27 perf]# perf test -F 40
        40: BPF filter                                            :
        40.1: Basic BPF filtering                                 : Ok
        40.2: BPF pinning                                         : Ok
        40.3: BPF prologue generation                             : Ok
        40.4: BPF relocation checker                              : Ok
        [root@p23lp27 perf]#
      
      Committer testing:
      
      While the above 'perf test -F 40' (or 'perf test bpf') will allow us
      to see that the correct path is now added via -I, to actually test this
      we better try to use a bpf script that includes files in the changed
      directory.
      
      We have the files that now reside in /root/lib/perf/examples/bpf/ to do
      just that:
      
        # tail -8 /root/lib/perf/examples/bpf/5sec.c
        #include <bpf.h>
      
        int probe(hrtimer_nanosleep, rqtp->tv_sec)(void *ctx, int err, long sec)
        {
      	  return sec == 5;
        }
      
        license(GPL);
        # perf trace -e *sleep -e /root/lib/perf/examples/bpf/5sec.c sleep 4
             0.333 (4000.086 ms): sleep/9248 nanosleep(rqtp: 0x7ffc155f3300) = 0
        # perf trace -e *sleep -e /root/lib/perf/examples/bpf/5sec.c sleep 5
             0.287 (         ): sleep/9659 nanosleep(rqtp: 0x7ffeafe38200) ...
             0.290 (         ): perf_bpf_probe:hrtimer_nanosleep:(ffffffff9911efe0) tv_sec=5
             0.287 (5000.059 ms): sleep/9659  ... [continued]: nanosleep()) = 0
        # perf trace -e *sleep -e /root/lib/perf/examples/bpf/5sec.c sleep 6
             0.247 (5999.951 ms): sleep/10068 nanosleep(rqtp: 0x7fff2086d900) = 0
        # perf trace -e *sleep -e /root/lib/perf/examples/bpf/5sec.c sleep 5.987
             0.293 (         ): sleep/10489 nanosleep(rqtp: 0x7ffdd4fc10e0) ...
             0.296 (         ): perf_bpf_probe:hrtimer_nanosleep:(ffffffff9911efe0) tv_sec=5
             0.293 (5986.912 ms): sleep/10489  ... [continued]: nanosleep()) = 0
        #
      Suggested-by: default avatarStefan Liebler <stli@linux.ibm.com>
      Suggested-by: default avatarArnaldo Carvalho de Melo <acme@kernel.org>
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Fixes: 1b16fffa ("perf llvm-utils: Add bpf include path to clang command line")
      Link: http://lkml.kernel.org/r/20180731073254.91090-1-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1e83b3b9
    • Kan Liang's avatar
      perf evlist: Fix error out while applying initial delay and LBR · d8551bc5
      Kan Liang authored
      [ Upstream commit 95035c5e ]
      
      'perf record' will error out if both --delay and LBR are applied.
      
      For example:
      
        # perf record -D 1000 -a -e cycles -j any -- sleep 2
        Error:
        dummy:HG: PMU Hardware doesn't support sampling/overflow-interrupts.
        Try 'perf stat'
        #
      
      A dummy event is added implicitly for initial delay, which has the same
      configurations as real sampling events. The dummy event is a software
      event. If LBR is configured, perf must error out.
      
      The dummy event will only be used to track PERF_RECORD_MMAP while perf
      waits for the initial delay to enable the real events. The BRANCH_STACK
      bit can be safely cleared for the dummy event.
      
      After applying the patch:
      
        # perf record -D 1000 -a -e cycles -j any -- sleep 2
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 1.054 MB perf.data (828 samples) ]
        #
      Reported-by: default avatarSunil K Pandey <sunil.k.pandey@intel.com>
      Signed-off-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1531145722-16404-1-git-send-email-kan.liang@linux.intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d8551bc5
    • Jiri Olsa's avatar
      perf c2c report: Fix crash for empty browser · 96e8b14b
      Jiri Olsa authored
      [ Upstream commit 73978332 ]
      
      'perf c2c' scans read/write accesses and tries to find false sharing
      cases, so when the events it wants were not asked for or ended up not
      taking place, we get no histograms.
      
      So do not try to display entry details if there's not any. Currently
      this ends up in crash:
      
        $ perf c2c report # then press 'd'
        perf: Segmentation fault
        $
      
      Committer testing:
      
      Before:
      
      Record a perf.data file without events of interest to 'perf c2c report',
      then call it and press 'd':
      
        # perf record sleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.001 MB perf.data (6 samples) ]
        # perf c2c report
        perf: Segmentation fault
        -------- backtrace --------
        perf[0x5b1d2a]
        /lib64/libc.so.6(+0x346df)[0x7fcb566e36df]
        perf[0x46fcae]
        perf[0x4a9f1e]
        perf[0x4aa220]
        perf(main+0x301)[0x42c561]
        /lib64/libc.so.6(__libc_start_main+0xe9)[0x7fcb566cff29]
        perf(_start+0x29)[0x42c999]
        #
      
      After the patch the segfault doesn't take place, a follow up patch to
      tell the user why nothing changes when 'd' is pressed would be good.
      
      Reported-by: rodia@autistici.org
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Joe Mario <jmario@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: f1c5fd4d ("perf c2c report: Add TUI cacheline browser")
      Link: http://lkml.kernel.org/r/20180724062008.26126-1-jolsa@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96e8b14b
    • Christophe Leroy's avatar
      perf tools: Allow overriding MAX_NR_CPUS at compile time · f2d46f40
      Christophe Leroy authored
      [ Upstream commit 21b8732e ]
      
      After update of kernel, the perf tool doesn't run anymore on my 32MB RAM
      powerpc board, but still runs on a 128MB RAM board:
      
        ~# strace perf
        execve("/usr/sbin/perf", ["perf"], [/* 12 vars */]) = -1 ENOMEM (Cannot allocate memory)
        --- SIGSEGV {si_signo=SIGSEGV, si_code=SI_KERNEL, si_addr=0} ---
        +++ killed by SIGSEGV +++
        Segmentation fault
      
      objdump -x shows that .bss section has a huge size of 24Mbytes:
      
       27 .bss          016baca8  101cebb8  101cebb8  001cd988  2**3
      
      With especially the following objects having quite big size:
      
        10205f80 l     O .bss	00140000     runtime_cycles_stats
        10345f80 l     O .bss	00140000     runtime_stalled_cycles_front_stats
        10485f80 l     O .bss	00140000     runtime_stalled_cycles_back_stats
        105c5f80 l     O .bss	00140000     runtime_branches_stats
        10705f80 l     O .bss	00140000     runtime_cacherefs_stats
        10845f80 l     O .bss	00140000     runtime_l1_dcache_stats
        10985f80 l     O .bss	00140000     runtime_l1_icache_stats
        10ac5f80 l     O .bss	00140000     runtime_ll_cache_stats
        10c05f80 l     O .bss	00140000     runtime_itlb_cache_stats
        10d45f80 l     O .bss	00140000     runtime_dtlb_cache_stats
        10e85f80 l     O .bss	00140000     runtime_cycles_in_tx_stats
        10fc5f80 l     O .bss	00140000     runtime_transaction_stats
        11105f80 l     O .bss	00140000     runtime_elision_stats
        11245f80 l     O .bss	00140000     runtime_topdown_total_slots
        11385f80 l     O .bss	00140000     runtime_topdown_slots_retired
        114c5f80 l     O .bss	00140000     runtime_topdown_slots_issued
        11605f80 l     O .bss	00140000     runtime_topdown_fetch_bubbles
        11745f80 l     O .bss	00140000     runtime_topdown_recovery_bubbles
      
      This is due to commit 4d255766 ("perf: Bump max number of cpus
      to 1024"), because many tables are sized with MAX_NR_CPUS
      
      This patch gives the opportunity to redefine MAX_NR_CPUS via
      
        $ make EXTRA_CFLAGS=-DMAX_NR_CPUS=1
      Signed-off-by: default avatarChristophe Leroy <christophe.leroy@c-s.fr>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/20170922112043.8349468C57@po15668-vm-win7.idsi0.si.c-s.frSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2d46f40
    • Roman Gushchin's avatar
      selftests/bpf: fix a typo in map in map test · c3b51c11
      Roman Gushchin authored
      [ Upstream commit 0069fb85 ]
      
      Commit fbeb1603 ("bpf: verifier: MOV64 don't mark dst reg unbounded")
      revealed a typo in commit fb30d4b7 ("bpf: Add tests for map-in-map"):
      BPF_MOV64_REG(BPF_REG_0, 0) was used instead of
      BPF_MOV64_IMM(BPF_REG_0, 0).
      
      I've noticed the problem by running bpf kselftests.
      
      Fixes: fb30d4b7 ("bpf: Add tests for map-in-map")
      Signed-off-by: default avatarRoman Gushchin <guro@fb.com>
      Cc: Martin KaFai Lau <kafai@fb.com>
      Cc: Arthur Fabre <afabre@cloudflare.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3b51c11
    • Vlad Buslov's avatar
      tc-testing: remove duplicate spaces in connmark match patterns · 40b9d96c
      Vlad Buslov authored
      [ Upstream commit 757a9a39 ]
      
      Match patterns for some connmark tests contain duplicate whitespace that is
      not present in actual tc output. This causes tests to fail because they
      can't match required action, even when it was successfully created.
      
      Fixes: 1dad0f9f ("tc-testing: add connmark action tests")
      Signed-off-by: default avatarVlad Buslov <vladbu@mellanox.com>
      Acked-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40b9d96c
    • Vlad Buslov's avatar
      tc-testing: flush gact actions on test teardown · 86bebb60
      Vlad Buslov authored
      [ Upstream commit 0c62f8a8 ]
      
      Test 6fb4 creates one mirred and one pipe action, but only flushes mirred
      on teardown. Leaking pipe action causes failures in other tests.
      
      Add additional teardown command to also flush gact actions.
      Signed-off-by: default avatarVlad Buslov <vladbu@mellanox.com>
      Acked-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86bebb60
  3. 15 Sep, 2018 4 commits
    • Breno Leitao's avatar
      selftests/powerpc: Kill child processes on SIGINT · c3fb1a35
      Breno Leitao authored
      [ Upstream commit 7c27a26e ]
      
      There are some powerpc selftests, as tm/tm-unavailable, that run for a long
      period (>120 seconds), and if it is interrupted, as pressing CRTL-C
      (SIGINT), the foreground process (harness) dies but the child process and
      threads continue to execute (with PPID = 1 now) in background.
      
      In this case, you'd think the whole test exited, but there are remaining
      threads and processes being executed in background. Sometimes these
      zombies processes are doing annoying things, as consuming the whole CPU or
      dumping things to STDOUT.
      
      This patch fixes this problem by attaching an empty signal handler to
      SIGINT in the harness process. This handler will interrupt (EINTR) the
      parent process waitpid() call, letting the code to follow through the
      normal flow, which will kill all the processes in the child process group.
      
      This patch also fixes a typo.
      Signed-off-by: default avatarBreno Leitao <leitao@debian.org>
      Signed-off-by: default avatarGustavo Romero <gromero@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3fb1a35
    • Sandipan Das's avatar
      perf probe powerpc: Fix trace event post-processing · c728031a
      Sandipan Das authored
      [ Upstream commit 354b064b ]
      
      In some cases, a symbol may have multiple aliases. Attempting to add an
      entry probe for such symbols results in a probe being added at an
      incorrect location while it fails altogether for return probes. This is
      only applicable for binaries with debug information.
      
      During the arch-dependent post-processing, the offset from the start of
      the symbol at which the probe is to be attached is determined and added
      to the start address of the symbol to get the probe's location.  In case
      there are multiple aliases, this offset gets added multiple times for
      each alias of the symbol and we end up with an incorrect probe location.
      
      This can be verified on a powerpc64le system as shown below.
      
        $ nm /lib/modules/$(uname -r)/build/vmlinux | grep "sys_open$"
        ...
        c000000000414290 T __se_sys_open
        c000000000414290 T sys_open
      
        $ objdump -d /lib/modules/$(uname -r)/build/vmlinux | grep -A 10 "<__se_sys_open>:"
      
        c000000000414290 <__se_sys_open>:
        c000000000414290:       19 01 4c 3c     addis   r2,r12,281
        c000000000414294:       70 c4 42 38     addi    r2,r2,-15248
        c000000000414298:       a6 02 08 7c     mflr    r0
        c00000000041429c:       e8 ff a1 fb     std     r29,-24(r1)
        c0000000004142a0:       f0 ff c1 fb     std     r30,-16(r1)
        c0000000004142a4:       f8 ff e1 fb     std     r31,-8(r1)
        c0000000004142a8:       10 00 01 f8     std     r0,16(r1)
        c0000000004142ac:       c1 ff 21 f8     stdu    r1,-64(r1)
        c0000000004142b0:       78 23 9f 7c     mr      r31,r4
        c0000000004142b4:       78 1b 7e 7c     mr      r30,r3
      
        For both the entry probe and the return probe, the probe location
        should be _text+4276888 (0xc000000000414298). Since another alias
        exists for 'sys_open', the post-processing code will end up adding
        the offset (8 for powerpc64le) twice and perf will attempt to add
        the probe at _text+4276896 (0xc0000000004142a0) instead.
      
      Before:
      
        # perf probe -v -a sys_open
      
        probe-definition(0): sys_open
        symbol:sys_open file:(null) line:0 offset:0 return:0 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (8 entries long)
        Using /lib/modules/4.18.0-rc8+/build/vmlinux for symbols
        Open Debuginfo file: /lib/modules/4.18.0-rc8+/build/vmlinux
        Try to find probe point from debuginfo.
        Symbol sys_open address found : c000000000414290
        Matched function: __se_sys_open [2ad03a0]
        Probe point found: __se_sys_open+0
        Found 1 probe_trace_events.
        Opening /sys/kernel/debug/tracing/kprobe_events write=1
        Writing event: p:probe/sys_open _text+4276896
        Added new event:
          probe:sys_open       (on sys_open)
        ...
      
        # perf probe -v -a sys_open%return $retval
      
        probe-definition(0): sys_open%return
        symbol:sys_open file:(null) line:0 offset:0 return:1 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (8 entries long)
        Using /lib/modules/4.18.0-rc8+/build/vmlinux for symbols
        Open Debuginfo file: /lib/modules/4.18.0-rc8+/build/vmlinux
        Try to find probe point from debuginfo.
        Symbol sys_open address found : c000000000414290
        Matched function: __se_sys_open [2ad03a0]
        Probe point found: __se_sys_open+0
        Found 1 probe_trace_events.
        Opening /sys/kernel/debug/tracing/README write=0
        Opening /sys/kernel/debug/tracing/kprobe_events write=1
        Parsing probe_events: p:probe/sys_open _text+4276896
        Group:probe Event:sys_open probe:p
        Writing event: r:probe/sys_open__return _text+4276896
        Failed to write event: Invalid argument
          Error: Failed to add events. Reason: Invalid argument (Code: -22)
      
      After:
      
        # perf probe -v -a sys_open
      
        probe-definition(0): sys_open
        symbol:sys_open file:(null) line:0 offset:0 return:0 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (8 entries long)
        Using /lib/modules/4.18.0-rc8+/build/vmlinux for symbols
        Open Debuginfo file: /lib/modules/4.18.0-rc8+/build/vmlinux
        Try to find probe point from debuginfo.
        Symbol sys_open address found : c000000000414290
        Matched function: __se_sys_open [2ad03a0]
        Probe point found: __se_sys_open+0
        Found 1 probe_trace_events.
        Opening /sys/kernel/debug/tracing/kprobe_events write=1
        Writing event: p:probe/sys_open _text+4276888
        Added new event:
          probe:sys_open       (on sys_open)
        ...
      
        # perf probe -v -a sys_open%return $retval
      
        probe-definition(0): sys_open%return
        symbol:sys_open file:(null) line:0 offset:0 return:1 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (8 entries long)
        Using /lib/modules/4.18.0-rc8+/build/vmlinux for symbols
        Open Debuginfo file: /lib/modules/4.18.0-rc8+/build/vmlinux
        Try to find probe point from debuginfo.
        Symbol sys_open address found : c000000000414290
        Matched function: __se_sys_open [2ad03a0]
        Probe point found: __se_sys_open+0
        Found 1 probe_trace_events.
        Opening /sys/kernel/debug/tracing/README write=0
        Opening /sys/kernel/debug/tracing/kprobe_events write=1
        Parsing probe_events: p:probe/sys_open _text+4276888
        Group:probe Event:sys_open probe:p
        Writing event: r:probe/sys_open__return _text+4276888
        Added new event:
          probe:sys_open__return (on sys_open%return)
        ...
      Reported-by: default avatarAneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
      Signed-off-by: default avatarSandipan Das <sandipan@linux.ibm.com>
      Acked-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
      Fixes: 99e608b5 ("perf probe ppc64le: Fix probe location when using DWARF")
      Link: http://lkml.kernel.org/r/20180809161929.35058-1-sandipan@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c728031a
    • Benno Evers's avatar
      perf tools: Check for null when copying nsinfo. · aa8ce04f
      Benno Evers authored
      [ Upstream commit 3f4417d6 ]
      
      The argument to nsinfo__copy() was assumed to be valid, but some code paths
      exist that will lead to NULL being passed.
      
      In particular, running 'perf script -D' on a perf.data file containing an
      PERF_RECORD_MMAP event associating the '[vdso]' dso with pid 0 earlier in
      the event stream will lead to a segfault.
      
      Since all calling code is already checking for a non-null return value,
      just return NULL for this case as well.
      Signed-off-by: default avatarBenno Evers <bevers@mesosphere.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Krister Johansen <kjlx@templeofstupid.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180810133614.9925-1-bevers@mesosphere.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      aa8ce04f
    • Kim Phillips's avatar
      perf arm spe: Fix uninitialized record error variable · faba3f03
      Kim Phillips authored
      [ Upstream commit 34435336 ]
      
      The auxtrace init variable 'err' was not being initialized, leading perf
      to abort early in an SPE record command when there was no explicit
      error, rather only based whatever memory contents were on the stack.
      Initialize it explicitly on getting an SPE successfully, the same way
      cs-etm does.
      Signed-off-by: default avatarKim Phillips <kim.phillips@arm.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Dongjiu Geng <gengdongjiu@huawei.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: ffd3d18c ("perf tools: Add ARM Statistical Profiling Extensions (SPE) support")
      Link: http://lkml.kernel.org/r/20180810174512.52900813e57cbccf18ce99a2@arm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      faba3f03
  4. 09 Sep, 2018 1 commit
  5. 05 Sep, 2018 1 commit
  6. 15 Aug, 2018 1 commit
  7. 08 Aug, 2018 1 commit
  8. 06 Aug, 2018 1 commit
  9. 03 Aug, 2018 1 commit
  10. 02 Aug, 2018 1 commit
  11. 30 Jul, 2018 6 commits
    • Yonghong Song's avatar
      tools/bpftool: fix a percpu_array map dump problem · 573b3aa6
      Yonghong Song authored
      I hit the following problem when I tried to use bpftool
      to dump a percpu array.
      
        $ sudo ./bpftool map show
        61: percpu_array  name stub  flags 0x0
                key 4B  value 4B  max_entries 1  memlock 4096B
        ...
        $ sudo ./bpftool map dump id 61
        bpftool: malloc.c:2406: sysmalloc: Assertion
        `(old_top == initial_top (av) && old_size == 0) || \
         ((unsigned long) (old_size) >= MINSIZE && \
         prev_inuse (old_top) && \
         ((unsigned long) old_end & (pagesize - 1)) == 0)'
        failed.
        Aborted
      
      Further debugging revealed that this is due to
      miscommunication between bpftool and kernel.
      For example, for the above percpu_array with value size of 4B.
      The map info returned to user space has value size of 4B.
      
      In bpftool, the values array for lookup is allocated like:
         info->value_size * get_possible_cpus() = 4 * get_possible_cpus()
      In kernel (kernel/bpf/syscall.c), the values array size is
      rounded up to multiple of 8.
         round_up(map->value_size, 8) * num_possible_cpus()
         = 8 * num_possible_cpus()
      So when kernel copies the values to user buffer, the kernel will
      overwrite beyond user buffer boundary.
      
      This patch fixed the issue by allocating and stepping through
      percpu map value array properly in bpftool.
      
      Fixes: 71bb428f ("tools: bpf: add bpftool")
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      573b3aa6
    • Arnaldo Carvalho de Melo's avatar
      perf tools: Fix the build on the alpine:edge distro · 44fe619b
      Arnaldo Carvalho de Melo authored
      The UAPI file byteorder/little_endian.h uses the __always_inline define
      without including the header where it is defined, linux/stddef.h, this
      ends up working in all the other distros because that file gets included
      seemingly by luck from one of the files included from little_endian.h.
      
      But not on Alpine:edge, that fails for all files where perf_event.h is
      included but linux/stddef.h isn't include before that.
      
      Adding the missing linux/stddef.h file where it breaks on Alpine:edge to
      fix that, in all other distros, that is just a very small header anyway.
      
      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-9r1pifftxvuxms8l7ir73p5l@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      44fe619b
    • Arnaldo Carvalho de Melo's avatar
      tools arch: Update arch/x86/lib/memcpy_64.S copy used in 'perf bench mem memcpy' · 1f27a050
      Arnaldo Carvalho de Melo authored
      To cope with the changes in:
      
        12c89130 ("x86/asm/memcpy_mcsafe: Add write-protection-fault handling")
        60622d68 ("x86/asm/memcpy_mcsafe: Return bytes remaining")
        bd131544 ("x86/asm/memcpy_mcsafe: Add labels for __memcpy_mcsafe() write fault handling")
        da7bc9c5 ("x86/asm/memcpy_mcsafe: Remove loop unrolling")
      
      This needed introducing a file with a copy of the mcsafe_handle_tail()
      function, that is used in the new memcpy_64.S file, as well as a dummy
      mcsafe_test.h header.
      
      Testing it:
      
        $ nm ~/bin/perf | grep mcsafe
        0000000000484130 T mcsafe_handle_tail
        0000000000484300 T __memcpy_mcsafe
        $
        $ perf bench mem memcpy
        # Running 'mem/memcpy' benchmark:
        # function 'default' (Default memcpy() provided by glibc)
        # Copying 1MB bytes ...
      
            44.389205 GB/sec
        # function 'x86-64-unrolled' (unrolled memcpy() in arch/x86/lib/memcpy_64.S)
        # Copying 1MB bytes ...
      
            22.710756 GB/sec
        # function 'x86-64-movsq' (movsq-based memcpy() in arch/x86/lib/memcpy_64.S)
        # Copying 1MB bytes ...
      
            42.459239 GB/sec
        # function 'x86-64-movsb' (movsb-based memcpy() in arch/x86/lib/memcpy_64.S)
        # Copying 1MB bytes ...
      
            42.459239 GB/sec
        $
      
      This silences this perf tools build warning:
      
        Warning: Kernel ABI header at 'tools/arch/x86/lib/memcpy_64.S' differs from latest version at 'arch/x86/lib/memcpy_64.S'
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Mika Penttilä <mika.penttila@nextfour.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-igdpciheradk3gb3qqal52d0@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      1f27a050
    • Arnaldo Carvalho de Melo's avatar
      tools headers uapi: Refresh linux/bpf.h copy · fc73bfd6
      Arnaldo Carvalho de Melo authored
      To get the changes in:
      
        4c79579b ("bpf: Change bpf_fib_lookup to return lookup status")
      
      That do not entail changes in tools/perf/ use of it, elliminating the
      following perf build warning:
      
        Warning: Kernel ABI header at 'tools/include/uapi/linux/bpf.h' differs from latest version at 'include/uapi/linux/bpf.h'
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      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-yei494y6b3mn6bjzz9g0ws12@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      fc73bfd6
    • Arnaldo Carvalho de Melo's avatar
      tools headers powerpc: Update asm/unistd.h copy to pick new · 7def16d1
      Arnaldo Carvalho de Melo authored
      The new 'io_pgetevents' syscall was wired up in PowerPC in the following
      cset:
      
        b2f82565 ("powerpc: Wire up io_pgetevents")
      
      Update tools/arch/powerpc/ copy of the asm/unistd.h file so that 'perf
      trace' on PowerPC gets it in its syscall table.
      
      This elliminated the following perf build warning:
      
        Warning: Kernel ABI header at 'tools/arch/powerpc/include/uapi/asm/unistd.h' differs from latest version at 'arch/powerpc/include/uapi/asm/unistd.h'
      
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Breno Leitao <leitao@debian.org>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Link: https://lkml.kernel.org/n/tip-9uvu7tz4ud3bxxfyxwryuz47@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      7def16d1
    • Arnaldo Carvalho de Melo's avatar
      tools headers uapi: Update tools's copy of linux/perf_event.h · 2c3ee0e1
      Arnaldo Carvalho de Melo authored
      To get the changes in:
      
        6cbc304f ("perf/x86/intel: Fix unwind errors from PEBS entries (mk-II)")
      
      That do not imply any changes in the tooling side, the (ab)use of
      sample_type is entirely done in kernel space, nothing for userspace to
      witness here.
      
      This cures the following warning during perf's build:
      
        Warning: Kernel ABI header at 'tools/include/uapi/linux/perf_event.h' differs from latest version at 'include/uapi/linux/perf_event.h'
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-o64mjoy35s9gd1gitunw1zg4@git.kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      2c3ee0e1