1. 27 Feb, 2019 11 commits
  2. 20 Feb, 2019 5 commits
    • Bob Tracy's avatar
      tools uapi: fix Alpha support · 24e99fcd
      Bob Tracy authored
      commit 842fc0f5 upstream.
      
      Cc: stable@vger.kernel.org # v4.18+
      Signed-off-by: 's avatarBob Tracy <rct@frus.com>
      Signed-off-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      24e99fcd
    • Aurelien Jarno's avatar
      tools uapi: fix RISC-V 64-bit support · 7e710bfd
      Aurelien Jarno authored
      [ Upstream commit d0df00e3 ]
      
      The BPF library is not built on 64-bit RISC-V, as the BPF feature is
      not detected. Looking more in details, feature/test-bpf.c fails to build
      with the following error:
      
      | In file included from /tmp/linux-4.19.12/tools/include/uapi/asm/bitsperlong.h:17,
      |                  from /tmp/linux-4.19.12/tools/include/uapi/asm-generic/unistd.h:2,
      |                  from /usr/include/riscv64-linux-gnu/asm/unistd.h:1,
      |                  from test-bpf.c:2:
      | /tmp/linux-4.19.12/tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
      |  #error Inconsistent word size. Check asm/bitsperlong.h
      |   ^~~~~
      
      The UAPI from the tools directory is missing RISC-V support, therefore
      bitsperlong.h from asm-generic is used, defaulting to 32 bits.
      
      Fix that by adding tools/arch/riscv/include/uapi/asm/bitsperlong.h as
      a copy of arch/riscv/include/uapi/asm/bitsperlong.h and by updating
      tools/include/uapi/asm/bitsperlong.h.
      Signed-off-by: 's avatarAurelien Jarno <aurelien@aurel32.net>
      Signed-off-by: 's avatarPalmer Dabbelt <palmer@sifive.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      7e710bfd
    • Arnaldo Carvalho de Melo's avatar
      perf test shell: Use a fallback to get the pathname in vfs_getname · 87d4f6ac
      Arnaldo Carvalho de Melo authored
      [ Upstream commit 03fa4838 ]
      
      Some kernels, like 4.19.13-300.fc29.x86_64 in fedora 29, fail with the
      existing probe definition asking for the contents of result->name,
      working when we ask for the 'filename' variable instead, so add a
      fallback to that.
      
      Now those tests are back working on fedora 29 systems with that kernel:
      
        # perf test vfs_getname
        65: Use vfs_getname probe to get syscall args filenames   : Ok
        66: Add vfs_getname probe to get syscall args filenames   : Ok
        67: Check open filename arg using perf trace + vfs_getname: Ok
        #
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: https://lkml.kernel.org/n/tip-klt3n0i58dfqttveti09q3fi@git.kernel.orgSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      87d4f6ac
    • Jin Yao's avatar
      perf report: Fix wrong iteration count in --branch-history · 394fc1c6
      Jin Yao authored
      [ Upstream commit a3366db0 ]
      
      By calculating the removed loops, we can get the iteration count.
      
      But the iteration count could be reported incorrectly, reporting
      impossibly high counts.
      
      That's because previous code uses the number of removed LBR entries for
      the iteration count. That's not good. Fix this by increasing the
      iteration count when a loop is detected.
      
      When matching the chain, the iteration count would be added up, finally we need
      to compute the average value when printing out.
      
      For example,
      
        $ perf report --branch-history --stdio --no-children
      
      Before:
      
        ---f2 +0
           |
           |--33.62%--f1 +9 (cycles:1)
           |          f1 +0
           |          main +22 (cycles:1)
           |          main +17
           |          main +38 (cycles:1)
           |          main +27
           |          f1 +26 (cycles:1)
           |          f1 +24
           |          f2 +27 (cycles:7)
           |          f2 +0
           |          f1 +19 (cycles:1)
           |          f1 +14
           |          f2 +27 (cycles:11)
           |          f2 +0
           |          f1 +9 (cycles:1 iter:2968 avg_cycles:3)
           |          f1 +0
           |          main +22 (cycles:1 iter:2968 avg_cycles:3)
           |          main +17
           |          main +38 (cycles:1 iter:2968 avg_cycles:3)
      
      2968 is an impossible high iteration count and avg_cycles is too small.
      
      After:
      
        ---f2 +0
           |
           |--33.62%--f1 +9 (cycles:1)
           |          f1 +0
           |          main +22 (cycles:1)
           |          main +17
           |          main +38 (cycles:1)
           |          main +27
           |          f1 +26 (cycles:1)
           |          f1 +24
           |          f2 +27 (cycles:7)
           |          f2 +0
           |          f1 +19 (cycles:1)
           |          f1 +14
           |          f2 +27 (cycles:11)
           |          f2 +0
           |          f1 +9 (cycles:1 iter:1 avg_cycles:23)
           |          f1 +0
           |          main +22 (cycles:1 iter:1 avg_cycles:23)
           |          main +17
           |          main +38 (cycles:1 iter:1 avg_cycles:23)
      
      avg_cycles:23 is the average cycles of this iteration.
      
      Fixes: c4ee0625 ("perf report: Calculate the average cycles of iterations")
      Signed-off-by: 's avatarJin Yao <yao.jin@linux.intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1546582230-17507-1-git-send-email-yao.jin@linux.intel.comSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      394fc1c6
    • Jin Yao's avatar
      perf stat: Fix endless wait for child process · 3902b972
      Jin Yao authored
      [ Upstream commit 8a99255a ]
      
      We hit a 'perf stat' issue by using following script:
      
        #!/bin/bash
      
        sleep 1000 &
        exec perf stat -a -e cycles -I1000 -- sleep 5
      
      Since "perf stat" is launched by exec, the "sleep 1000" would be the
      child process of "perf stat". The wait4() call will not return because
      it's waiting for the child process "sleep 1000" to end. So 'perf stat'
      doesn't return even after 5s passes.
      
      This patch lets 'perf stat' return when the specified child process ends
      (in this case, the specified child process is "sleep 5").
      
      Committer testing:
      
        # cat test.sh
        #!/bin/bash
      
        sleep 10 &
        exec perf stat -a -e cycles -I1000 -- sleep 5
        #
      
      Before:
      
        # time ./test.sh
        #           time             counts unit events
             1.001113090        108,453,351      cycles
             2.002062196        142,075,435      cycles
             3.002896194        164,801,068      cycles
             4.003731666        107,062,140      cycles
             5.002068867        112,241,832      cycles
      
        real	0m10.066s
        user	0m0.016s
        sys	0m0.101s
        #
      
      After:
      
        # time ./test.sh
        #           time             counts unit events
             1.001016096         91,412,027      cycles
             2.002014963        124,063,708      cycles
             3.002883964        125,993,929      cycles
             4.003706470        120,465,734      cycles
             5.002006778        163,560,355      cycles
      
        real	0m5.123s
        user	0m0.014s
        sys	0m0.105s
        #
      Signed-off-by: 's avatarJin Yao <yao.jin@linux.intel.com>
      Reviewed-by: 's avatarJiri Olsa <jolsa@kernel.org>
      Tested-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1546501245-4512-1-git-send-email-yao.jin@linux.intel.comSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      3902b972
  3. 15 Feb, 2019 1 commit
  4. 12 Feb, 2019 19 commits
  5. 06 Feb, 2019 1 commit
  6. 31 Jan, 2019 1 commit
    • Dave Hansen's avatar
      x86/selftests/pkeys: Fork() to check for state being preserved · 940343c7
      Dave Hansen authored
      commit e1812933 upstream.
      
      There was a bug where the per-mm pkey state was not being preserved across
      fork() in the child.  fork() is performed in the pkey selftests, but all of
      the pkey activity is performed in the parent.  The child does not perform
      any actions sensitive to pkey state.
      
      To make the test more sensitive to these kinds of bugs, add a fork() where
      the parent exits, and execution continues in the child.
      
      To achieve this let the key exhaustion test not terminate at the first
      allocation failure and fork after 2*NR_PKEYS loops and continue in the
      child.
      Signed-off-by: 's avatarDave Hansen <dave.hansen@linux.intel.com>
      Signed-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Cc: bp@alien8.de
      Cc: hpa@zytor.com
      Cc: peterz@infradead.org
      Cc: mpe@ellerman.id.au
      Cc: will.deacon@arm.com
      Cc: luto@kernel.org
      Cc: jroedel@suse.de
      Cc: stable@vger.kernel.org
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Joerg Roedel <jroedel@suse.de>
      Link: https://lkml.kernel.org/r/20190102215657.585704B7@viggo.jf.intel.comSigned-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      940343c7
  7. 26 Jan, 2019 2 commits