1. 09 2月, 2018 1 次提交
  2. 30 1月, 2018 3 次提交
    • J
      objtool: Warn on stripped section symbol · 830c1e3d
      Josh Poimboeuf 提交于
      With the following fix:
      
        2a0098d7 ("objtool: Fix seg fault with gold linker")
      
      ... a seg fault was avoided, but the original seg fault condition in
      objtool wasn't fixed.  Replace the seg fault with an error message.
      Suggested-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/dc4585a70d6b975c99fc51d1957ccdde7bd52f3a.1517284349.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      830c1e3d
    • J
      objtool: Add support for alternatives at the end of a section · 17bc3391
      Josh Poimboeuf 提交于
      Now that the previous patch gave objtool the ability to read retpoline
      alternatives, it shows a new warning:
      
        arch/x86/entry/entry_64.o: warning: objtool: .entry_trampoline: don't know how to handle alternatives at end of section
      
      This is due to the JMP_NOSPEC in entry_SYSCALL_64_trampoline().
      
      Previously, objtool ignored this situation because it wasn't needed, and
      it would have required a bit of extra code.  Now that this case exists,
      add proper support for it.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/2a30a3c2158af47d891a76e69bb1ef347e0443fd.1517284349.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      17bc3391
    • J
      objtool: Improve retpoline alternative handling · a845c7cf
      Josh Poimboeuf 提交于
      Currently objtool requires all retpolines to be:
      
        a) patched in with alternatives; and
      
        b) annotated with ANNOTATE_NOSPEC_ALTERNATIVE.
      
      If you forget to do both of the above, objtool segfaults trying to
      dereference a NULL 'insn->call_dest' pointer.
      
      Avoid that situation and print a more helpful error message:
      
        quirks.o: warning: objtool: efi_delete_dummy_variable()+0x99: unsupported intra-function call
        quirks.o: warning: objtool: If this is a retpoline, please patch it in with alternatives and annotate it with ANNOTATE_NOSPEC_ALTERNATIVE.
      
      Future improvements can be made to make objtool smarter with respect to
      retpolines, but this is a good incremental improvement for now.
      Reported-and-tested-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/819e50b6d9c2e1a22e34c1a636c0b2057cc8c6e5.1517284349.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      a845c7cf
  3. 18 1月, 2018 1 次提交
    • D
      bpf: mark dst unknown on inconsistent {s, u}bounds adjustments · 6f16101e
      Daniel Borkmann 提交于
      syzkaller generated a BPF proglet and triggered a warning with
      the following:
      
        0: (b7) r0 = 0
        1: (d5) if r0 s<= 0x0 goto pc+0
         R0=inv0 R1=ctx(id=0,off=0,imm=0) R10=fp0
        2: (1f) r0 -= r1
         R0=inv0 R1=ctx(id=0,off=0,imm=0) R10=fp0
        verifier internal error: known but bad sbounds
      
      What happens is that in the first insn, r0's min/max value
      are both 0 due to the immediate assignment, later in the jsle
      test the bounds are updated for the min value in the false
      path, meaning, they yield smin_val = 1, smax_val = 0, and when
      ctx pointer is subtracted from r0, verifier bails out with the
      internal error and throwing a WARN since smin_val != smax_val
      for the known constant.
      
      For min_val > max_val scenario it means that reg_set_min_max()
      and reg_set_min_max_inv() (which both refine existing bounds)
      demonstrated that such branch cannot be taken at runtime.
      
      In above scenario for the case where it will be taken, the
      existing [0, 0] bounds are kept intact. Meaning, the rejection
      is not due to a verifier internal error, and therefore the
      WARN() is not necessary either.
      
      We could just reject such cases in adjust_{ptr,scalar}_min_max_vals()
      when either known scalars have smin_val != smax_val or
      umin_val != umax_val or any scalar reg with bounds
      smin_val > smax_val or umin_val > umax_val. However, there
      may be a small risk of breakage of buggy programs, so handle
      this more gracefully and in adjust_{ptr,scalar}_min_max_vals()
      just taint the dst reg as unknown scalar when we see ops with
      such kind of src reg.
      
      Reported-by: syzbot+6d362cadd45dc0a12ba4@syzkaller.appspotmail.com
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      6f16101e
  4. 17 1月, 2018 1 次提交
  5. 16 1月, 2018 1 次提交
  6. 14 1月, 2018 1 次提交
  7. 13 1月, 2018 1 次提交
    • A
      selftests/x86: Add test_vsyscall · 352909b4
      Andy Lutomirski 提交于
      This tests that the vsyscall entries do what they're expected to do.
      It also confirms that attempts to read the vsyscall page behave as
      expected.
      
      If changes are made to the vsyscall code or its memory map handling,
      running this test in all three of vsyscall=none, vsyscall=emulate,
      and vsyscall=native are helpful.
      
      (Because it's easy, this also compares the vsyscall results to their
       vDSO equivalents.)
      
      Note to KAISER backporters: please test this under all three
      vsyscall modes.  Also, in the emulate and native modes, make sure
      that test_vsyscall_64 agrees with the command line or config
      option as to which mode you're in.  It's quite easy to mess up
      the kernel such that native mode accidentally emulates
      or vice versa.
      
      Greg, etc: please backport this to all your Meltdown-patched
      kernels.  It'll help make sure the patches didn't regress
      vsyscalls.
      CSigned-off-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/2b9c5a174c1d60fd7774461d518aa75598b1d8fd.1515719552.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      352909b4
  8. 12 1月, 2018 2 次提交
    • J
      objtool: Allow alternatives to be ignored · 258c7605
      Josh Poimboeuf 提交于
      Getting objtool to understand retpolines is going to be a bit of a
      challenge.  For now, take advantage of the fact that retpolines are
      patched in with alternatives.  Just read the original (sane)
      non-alternative instruction, and ignore the patched-in retpoline.
      
      This allows objtool to understand the control flow *around* the
      retpoline, even if it can't yet follow what's inside.  This means the
      ORC unwinder will fail to unwind from inside a retpoline, but will work
      fine otherwise.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: gnomes@lxorguk.ukuu.org.uk
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: thomas.lendacky@amd.com
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Kees Cook <keescook@google.com>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
      Cc: Paul Turner <pjt@google.com>
      Link: https://lkml.kernel.org/r/1515707194-20531-3-git-send-email-dwmw@amazon.co.uk
      258c7605
    • J
      objtool: Detect jumps to retpoline thunks · 39b73533
      Josh Poimboeuf 提交于
      A direct jump to a retpoline thunk is really an indirect jump in
      disguise.  Change the objtool instruction type accordingly.
      
      Objtool needs to know where indirect branches are so it can detect
      switch statement jump tables.
      
      This fixes a bunch of warnings with CONFIG_RETPOLINE like:
      
        arch/x86/events/intel/uncore_nhmex.o: warning: objtool: nhmex_rbox_msr_enable_event()+0x44: sibling call from callable instruction with modified stack frame
        kernel/signal.o: warning: objtool: copy_siginfo_to_user()+0x91: sibling call from callable instruction with modified stack frame
        ...
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NDavid Woodhouse <dwmw@amazon.co.uk>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: gnomes@lxorguk.ukuu.org.uk
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: thomas.lendacky@amd.com
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Jiri Kosina <jikos@kernel.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Kees Cook <keescook@google.com>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
      Cc: Paul Turner <pjt@google.com>
      Link: https://lkml.kernel.org/r/1515707194-20531-2-git-send-email-dwmw@amazon.co.uk
      39b73533
  9. 11 1月, 2018 1 次提交
    • D
      bpf: arsh is not supported in 32 bit alu thus reject it · 7891a87e
      Daniel Borkmann 提交于
      The following snippet was throwing an 'unknown opcode cc' warning
      in BPF interpreter:
      
        0: (18) r0 = 0x0
        2: (7b) *(u64 *)(r10 -16) = r0
        3: (cc) (u32) r0 s>>= (u32) r0
        4: (95) exit
      
      Although a number of JITs do support BPF_ALU | BPF_ARSH | BPF_{K,X}
      generation, not all of them do and interpreter does neither. We can
      leave existing ones and implement it later in bpf-next for the
      remaining ones, but reject this properly in verifier for the time
      being.
      
      Fixes: 17a52670 ("bpf: verifier (add verifier core)")
      Reported-by: syzbot+93c4904c5c70348a6890@syzkaller.appspotmail.com
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      7891a87e
  10. 07 1月, 2018 1 次提交
  11. 31 12月, 2017 2 次提交
  12. 28 12月, 2017 1 次提交
  13. 24 12月, 2017 1 次提交
    • T
      x86/ldt: Make the LDT mapping RO · 9f5cb6b3
      Thomas Gleixner 提交于
      Now that the LDT mapping is in a known area when PAGE_TABLE_ISOLATION is
      enabled its a primary target for attacks, if a user space interface fails
      to validate a write address correctly. That can never happen, right?
      
      The SDM states:
      
          If the segment descriptors in the GDT or an LDT are placed in ROM, the
          processor can enter an indefinite loop if software or the processor
          attempts to update (write to) the ROM-based segment descriptors. To
          prevent this problem, set the accessed bits for all segment descriptors
          placed in a ROM. Also, remove operating-system or executive code that
          attempts to modify segment descriptors located in ROM.
      
      So its a valid approach to set the ACCESS bit when setting up the LDT entry
      and to map the table RO. Fixup the selftest so it can handle that new mode.
      
      Remove the manual ACCESS bit setter in set_tls_desc() as this is now
      pointless. Folded the patch from Peter Ziljstra.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      9f5cb6b3
  14. 23 12月, 2017 3 次提交
  15. 22 12月, 2017 1 次提交
  16. 21 12月, 2017 4 次提交
    • S
      tools/kvm_stat: sort '-f help' output · aa12f594
      Stefan Raspl 提交于
      Sort the fields returned by specifying '-f help' on the command line.
      While at it, simplify the code a bit, indent the output and eliminate an
      extra blank line at the beginning.
      Signed-off-by: NStefan Raspl <raspl@linux.vnet.ibm.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      aa12f594
    • A
      bpf: do not allow root to mangle valid pointers · 82abbf8d
      Alexei Starovoitov 提交于
      Do not allow root to convert valid pointers into unknown scalars.
      In particular disallow:
       ptr &= reg
       ptr <<= reg
       ptr += ptr
      and explicitly allow:
       ptr -= ptr
      since pkt_end - pkt == length
      
      1.
      This minimizes amount of address leaks root can do.
      In the future may need to further tighten the leaks with kptr_restrict.
      
      2.
      If program has such pointer math it's likely a user mistake and
      when verifier complains about it right away instead of many instructions
      later on invalid memory access it's easier for users to fix their progs.
      
      3.
      when register holding a pointer cannot change to scalar it allows JITs to
      optimize better. Like 32-bit archs could use single register for pointers
      instead of a pair required to hold 64-bit scalars.
      
      4.
      reduces architecture dependent behavior. Since code:
      r1 = r10;
      r1 &= 0xff;
      if (r1 ...)
      will behave differently arm64 vs x64 and offloaded vs native.
      
      A significant chunk of ptr mangling was allowed by
      commit f1174f77 ("bpf/verifier: rework value tracking")
      yet some of it was allowed even earlier.
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      82abbf8d
    • J
      selftests/bpf: add tests for recent bugfixes · 2255f8d5
      Jann Horn 提交于
      These tests should cover the following cases:
      
       - MOV with both zero-extended and sign-extended immediates
       - implicit truncation of register contents via ALU32/MOV32
       - implicit 32-bit truncation of ALU32 output
       - oversized register source operand for ALU32 shift
       - right-shift of a number that could be positive or negative
       - map access where adding the operation size to the offset causes signed
         32-bit overflow
       - direct stack access at a ~4GiB offset
      
      Also remove the F_LOAD_WITH_STRICT_ALIGNMENT flag from a bunch of tests
      that should fail independent of what flags userspace passes.
      Signed-off-by: NJann Horn <jannh@google.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      2255f8d5
    • N
      selftests: net: Adding config fragment CONFIG_NUMA=y · 1c8e77fb
      Naresh Kamboju 提交于
      kernel config fragement CONFIG_NUMA=y is need for reuseport_bpf_numa.
      Signed-off-by: NNaresh Kamboju <naresh.kamboju@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c8e77fb
  17. 20 12月, 2017 1 次提交
  18. 19 12月, 2017 2 次提交
    • J
      usbip: fix usbip bind writing random string after command in match_busid · 544c4605
      Juan Zea 提交于
      usbip bind writes commands followed by random string when writing to
      match_busid attribute in sysfs, caused by using full variable size
      instead of string length.
      Signed-off-by: NJuan Zea <juan.zea@qindel.com>
      Acked-by: NShuah Khan <shuahkh@osg.samsung.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      544c4605
    • H
      bpf: fix broken BPF selftest build on s390 · c682ccc4
      Hendrik Brueckner 提交于
      With 720f228e ("bpf: fix broken BPF selftest build") the
      inclusion of arch-specific header files changed.  Including the
      asm/bpf_perf_event.h on s390, correctly includes the s390 specific
      header file.  This header file tries then to include the s390
      asm/ptrace.h and the build fails with:
      
      cc -Wall -O2 -I../../../include/uapi -I../../../lib -I../../../../include/generated  -I../../../include    test_verifier.c
      +/root/git/linux/tools/testing/selftests/bpf/libbpf.a /root/git/linux/tools/testing/selftests/bpf/cgroup_helpers.c -lcap -lelf -o
      +/root/git/linux/tools/testing/selftests/bpf/test_verifier
      In file included from ../../../include/uapi/asm/bpf_perf_event.h:4:0,
                       from ../../../include/uapi/linux/bpf_perf_event.h:11,
                       from test_verifier.c:29:
      ../../../include/uapi/../../arch/s390/include/uapi/asm/bpf_perf_event.h:7:9: error: unknown type name 'user_pt_regs'
       typedef user_pt_regs bpf_user_pt_regs_t;
               ^~~~~~~~~~~~
      make: *** [../lib.mk:109: /root/git/linux/tools/testing/selftests/bpf/test_verifier] Error 1
      
      This is caused by a recent update to the s390 asm/ptrace.h file
      that is not (yet) available in the local installation.  That means,
      the s390 asm/ptrace.h must be included from the tools/arch/s390
      directory.
      
      Because there is no proper framework to deal with asm specific
      includes in tools/, slightly modify the s390 asm/bpf_perf_event.h
      to include the local ptrace.h header file.
      
      See also discussion on
      https://marc.info/?l=linux-s390&m=151359424420691&w=2
      
      Please note that this needs to be preserved until tools/ is able to
      correctly handle asm specific headers.
      
      References: https://marc.info/?l=linux-s390&m=151359424420691&w=2
      Fixes: 720f228e ("bpf: fix broken BPF selftest build")
      Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      c682ccc4
  19. 18 12月, 2017 4 次提交
    • A
      tools arch s390: Do not include header files from the kernel sources · 10b9baa7
      Arnaldo Carvalho de Melo 提交于
      Long ago we decided to be verbotten including files in the kernel git
      sources from tools/ living source code, to avoid disturbing kernel
      development (and perf's and other tools/) when, say, a kernel hacker
      adds something, tests everything but tools/ and have tools/ build
      broken.
      
      This got broken recently by s/390, fix it by copying
      arch/s390/include/uapi/asm/perf_regs.h to tools/arch/s390/include/uapi/asm/,
      making this one be used by means of <asm/perf_regs.h> and updating
      tools/perf/check_headers.sh to make sure we are notified when the
      original changes, so that we can check if anything is needed on the
      tooling side.
      
      This would have been caught by the 'tarkpg' test entry in:
      
      $ make -C tools/perf build-test
      
      When run on a s/390 build system or container.
      Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      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>
      Fixes: f704ef44 ("s390/perf: add support for perf_regs and libdw")
      Link: https://lkml.kernel.org/n/tip-n57139ic0v9uffx8wdqi3d8a@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      10b9baa7
    • B
      perf jvmti: Generate correct debug information for inlined code · ca58d7e6
      Ben Gainey 提交于
      tools/perf/jvmti is broken in so far as it generates incorrect debug
      information. Specifically it attributes all debug lines to the original
      method being output even in the case that some code is being inlined
      from elsewhere.  This patch fixes the issue.
      
      To test (from within linux/tools/perf):
      
      export JDIR=/usr/lib/jvm/java-8-openjdk-amd64/
      make
      cat << __EOF > Test.java
      public class Test
      {
          private StringBuilder b = new StringBuilder();
      
          private void loop(int i, String... args)
          {
              for (String a : args)
                  b.append(a);
      
              long hc = b.hashCode() * System.nanoTime();
      
              b = new StringBuilder();
              b.append(hc);
      
              System.out.printf("Iteration %d = %d\n", i, hc);
          }
      
          public void run(String... args)
          {
              for (int i = 0; i < 10000; ++i)
              {
                  loop(i, args);
              }
          }
      
          public static void main(String... args)
          {
              Test t = new Test();
              t.run(args);
          }
      }
      __EOF
      $JDIR/bin/javac Test.java
      ./perf record -F 10000 -g -k mono $JDIR/bin/java -agentpath:`pwd`/libperf-jvmti.so Test
      ./perf inject --jit -i perf.data -o perf.data.jitted
      ./perf annotate -i perf.data.jitted --stdio | grep Test\.java: | sort -u
      
      Before this patch, Test.java line numbers get reported that are greater
      than the number of lines in the Test.java file.  They come from the
      source file of the inlined function, e.g. java/lang/String.java:1085.
      For further validation one can examine those lines in the JDK source
      distribution and confirm that they map to inlined functions called by
      Test.java.
      
      After this patch, the filename of the inlined function is output
      rather than the incorrect original source filename.
      Signed-off-by: NBen Gainey <ben.gainey@arm.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Tested-by: NStephane Eranian <eranian@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ben Gainey <ben.gainey@arm.com>
      Cc: Colin King <colin.king@canonical.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 598b7c69 ("perf jit: add source line info support")
      Link: http://lkml.kernel.org/r/20171122182541.d25599a3eb1ada3480d142fa@arm.comSigned-off-by: NKim Phillips <kim.phillips@arm.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ca58d7e6
    • J
      perf tools: Fix up build in hardened environments · 61fb26a6
      Jiri Olsa 提交于
      On Fedora systems the perl and python CFLAGS/LDFLAGS include the
      hardened specs from redhat-rpm-config package. We apply them only for
      perl/python objects, which makes them not compatible with the rest of
      the objects and the build fails with:
      
        /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -f
      +PIC
        /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile w
      +ith -fPIC
        /usr/bin/ld: final link failed: Nonrepresentable section on output
        collect2: error: ld returned 1 exit status
        make[2]: *** [Makefile.perf:507: perf] Error 1
        make[1]: *** [Makefile.perf:210: sub-make] Error 2
        make: *** [Makefile:69: all] Error 2
      
      Mainly it's caused by perl/python objects being compiled with:
      
        -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
      
      which prevent the final link impossible, because it will check
      for 'proper' objects with following option:
      
        -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/20171204082437.GC30564@kravaSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      61fb26a6
    • J
      perf tools: Use shell function for perl cflags retrieval · 5cfee7a3
      Jiri Olsa 提交于
      Using the shell function for perl CFLAGS retrieval instead of back
      quotes (``). Both execute shell with the command, but the latter is more
      explicit and seems to be the preferred way.
      
      Also we don't have any other use of the back quotes in perf Makefiles.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20171108102739.30338-2-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5cfee7a3
  20. 16 12月, 2017 1 次提交
  21. 15 12月, 2017 4 次提交
  22. 14 12月, 2017 3 次提交