1. 09 7月, 2020 3 次提交
    • N
      perf annotate: Fix non-null terminated buffer returned by readlink() · b39730a6
      Numfor Mbiziwo-Tiapo 提交于
      Our local MSAN (Memory Sanitizer) build of perf throws a warning that
      comes from the "dso__disassemble_filename" function in
      "tools/perf/util/annotate.c" when running perf record.
      
      The warning stems from the call to readlink, in which "build_id_path"
      was being read into "linkname". Since readlink does not null terminate,
      an uninitialized memory access would later occur when "linkname" is
      passed into the strstr function. This is simply fixed by
      null-terminating "linkname" after the call to readlink.
      
      To reproduce this warning, build perf by running:
      
        $ make -C tools/perf CLANG=1 CC=clang EXTRA_CFLAGS="-fsanitize=memory -fsanitize-memory-track-origins"
      
      (Additionally, llvm might have to be installed and clang might have to
      be specified as the compiler - export CC=/usr/bin/clang)
      
      Then running:
      
        tools/perf/perf record -o - ls / | tools/perf/perf --no-pager annotate -i - --stdio
      
      Please see the cover letter for why false positive warnings may be
      generated.
      Signed-off-by: NNumfor Mbiziwo-Tiapo <nums@google.com>
      Acked-by: NIan Rogers <irogers@google.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Mark Drayton <mbd@fb.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lore.kernel.org/lkml/20190729205750.193289-1-nums@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b39730a6
    • S
      perf inject jit: Remove //anon mmap events · c8f6ae1f
      Steve MacLean 提交于
      **perf-<pid>.map and jit-<pid>.dump designs:
      
      When a JIT generates code to be executed, it must allocate memory and
      mark it executable using an mmap call.
      
      *** perf-<pid>.map design
      
      The perf-<pid>.map assumes that any sample recorded in an anonymous
      memory page is JIT code. It then tries to resolve the symbol name by
      looking at the process' perf-<pid>.map.
      
      *** jit-<pid>.dump design
      
      The jit-<pid>.dump mechanism takes a different approach. It requires a
      JIT to write a `<path>/jit-<pid>.dump` file. This file must also be
      mmapped so that perf inject -jit can find the file. The JIT must also
      add JIT_CODE_LOAD records for any functions it generates. The records
      are timestamped using a clock which can be correlated to the perf record
      clock.
      
      After perf record,  the `perf inject -jit` pass parses the recording
      looking for a `<path>/jit-<pid>.dump` file. When it finds the file, it
      parses it and for each JIT_CODE_LOAD record:
      * creates an elf file `<path>/jitted-<pid>-<code_index>.so
      * injects a new mmap record mapping the new elf file into the process.
      
      *** Coexistence design
      
      The kernel and perf support both of these mechanisms. We need to make
      sure perf works on an app supporting either or both of these mechanisms.
      Both designs rely on mmap records to determine how to resolve an ip
      address.
      
      The mmap records of both techniques by definition overlap. When the JIT
      compiles a method, it must:
      
      * allocate memory (mmap)
      * add execution privilege (mprotect or mmap. either will
      generate an mmap event form the kernel to perf)
      * compile code into memory
      * add a function record to perf-<pid>.map and/or jit-<pid>.dump
      
      Because the jit-<pid>.dump mechanism supports greater capabilities, perf
      prefers the symbols from jit-<pid>.dump. It implements this based on
      timestamp ordering of events. There is an implicit ASSUMPTION that the
      JIT_CODE_LOAD record timestamp will be after the // anon mmap event that
      was generated during memory allocation or adding the execution privilege setting.
      
      *** Problems with the ASSUMPTION
      
      The ASSUMPTION made in the Coexistence design section above is violated
      in the following scenario.
      
      *** Scenario
      
      While a JIT is jitting code it will eventually need to commit more
      pages and change these pages to executable permissions. Typically the
      JIT will want these collocated to minimize branch displacements.
      
      The kernel will coalesce these anonymous mapping with identical
      permissions before sending an MMAP event for the new pages. The address
      range of the new mmap will not be just the most recently mmap pages.
      It will include the entire coalesced mmap region.
      
      See mm/mmap.c
      
      unsigned long mmap_region(struct file *file, unsigned long addr,
                      unsigned long len, vm_flags_t vm_flags, unsigned long pgoff,
                      struct list_head *uf)
      {
      ...
              /*
               * Can we just expand an old mapping?
               */
      ...
              perf_event_mmap(vma);
      ...
      }
      
      *** Symptoms
      
      The coalesced // anon mmap event will be timestamped after the
      JIT_CODE_LOAD records. This means it will be used as the most recent
      mapping for that entire address range. For remaining events it will look
      at the inferior perf-<pid>.map for symbols.
      
      If both mechanisms are supported, the symbol will appear twice with
      different module names. This causes weird behavior in reporting.
      
      If only jit-<pid>.dump is supported, the symbol will no longer be resolved.
      
      ** Implemented solution
      
      This patch solves the issue by removing // anon mmap events for any
      process which has a valid jit-<pid>.dump file.
      
      It tracks on a per process basis to handle the case where some running
      apps support jit-<pid>.dump, but some only support perf-<pid>.map.
      
      It adds new assumptions:
      * // anon mmap events are only required for perf-<pid>.map support.
      * An app that uses jit-<pid>.dump, no longer needs
      perf-<pid>.map support. It assumes that any perf-<pid>.map info is
      inferior.
      
      *** Details
      
      Use thread->priv to store whether a jitdump file has been processed
      
      During "perf inject --jit", discard "//anon*" mmap events for any pid which
      has sucessfully processed a jitdump file.
      
      ** Testing:
      
      // jitdump case
      
        perf record <app with jitdump>
        perf inject --jit --input perf.data --output perfjit.data
      
      // verify mmap "//anon" events present initially
      
        perf script --input perf.data --show-mmap-events | grep '//anon'
      
      // verify mmap "//anon" events removed
      
        perf script --input perfjit.data --show-mmap-events | grep '//anon'
      
      // no jitdump case
      
        perf record <app without jitdump>
        perf inject --jit --input perf.data --output perfjit.data
      
      // verify mmap "//anon" events present initially
      
        perf script --input perf.data --show-mmap-events | grep '//anon'
      
      // verify mmap "//anon" events not removed
      
        perf script --input perfjit.data --show-mmap-events | grep '//anon'
      
      ** Repro:
      
      This issue was discovered while testing the initial CoreCLR jitdump
      implementation. https://github.com/dotnet/coreclr/pull/26897.
      
      ** Alternate solutions considered
      
      These were also briefly considered:
      
      * Change kernel to not coalesce mmap regions.
      
      * Change kernel reporting of coalesced mmap regions to perf. Only
      include newly mapped memory.
      
      * Only strip parts of // anon mmap events overlapping existing
      jitted-<pid>-<code_index>.so mmap events.
      Signed-off-by: NSteve MacLean <Steve.MacLean@Microsoft.com>
      Acked-by: NIan Rogers <irogers@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lore.kernel.org/lkml/1590544271-125795-1-git-send-email-steve.maclean@linux.microsoft.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c8f6ae1f
    • A
      Merge remote-tracking branch 'torvalds/master' into perf/core · facbf0b9
      Arnaldo Carvalho de Melo 提交于
      To pick up fixes and move perf/core forward, minor conflict as
      perf_evlist__add_dummy() lost its 'perf_' prefix as it operates on a
      'struct evlist', not on a 'struct perf_evlist', i.e. its tools/perf/
      specific, it is not in libperf.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      facbf0b9
  2. 08 7月, 2020 7 次提交
  3. 07 7月, 2020 4 次提交
    • J
      Revert commit e918e570 ("tpm_tis: Remove the HID IFX0102") · 786a2aa2
      Jarkko Sakkinen 提交于
      Removing IFX0102 from tpm_tis was not a right move because both tpm_tis
      and tpm_infineon use the same device ID. Revert the commit and add a
      remark about a bug caused by commit 93e1b7d4 ("[PATCH] tpm: add HID
      module parameter").
      
      Fixes: e918e570 ("tpm_tis: Remove the HID IFX0102")
      Reported-by: NPeter Huewe <peterhuewe@gmx.de>
      Reviewed-by: NJerry Snitselaar <jsnitsel@redhat.com>
      Signed-off-by: NJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      786a2aa2
    • L
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · bfe91da2
      Linus Torvalds 提交于
      Pull kvm fixes from Paolo Bonzini:
       "Bugfixes and a one-liner patch to silence a sparse warning"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: arm64: Stop clobbering x0 for HVC_SOFT_RESTART
        KVM: arm64: PMU: Fix per-CPU access in preemptible context
        KVM: VMX: Use KVM_POSSIBLE_CR*_GUEST_BITS to initialize guest/host masks
        KVM: x86: Mark CR4.TSD as being possibly owned by the guest
        KVM: x86: Inject #GP if guest attempts to toggle CR4.LA57 in 64-bit mode
        kvm: use more precise cast and do not drop __user
        KVM: x86: bit 8 of non-leaf PDPEs is not reserved
        KVM: X86: Fix async pf caused null-ptr-deref
        KVM: arm64: vgic-v4: Plug race between non-residency and v4.1 doorbell
        KVM: arm64: pvtime: Ensure task delay accounting is enabled
        KVM: arm64: Fix kvm_reset_vcpu() return code being incorrect with SVE
        KVM: arm64: Annotate hyp NMI-related functions as __always_inline
        KVM: s390: reduce number of IO pins to 1
      bfe91da2
    • L
      Merge tag 's390-5.8-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · 5c82ec00
      Linus Torvalds 提交于
      Pull s390 fixes from Heiko Carstens:
      
       - Initialize jump labels before early command line parsing in order to
         make init_on_alloc and init_on_free options work
      
       - Fix vfio-ccw build error due to missing include
      
       - Prevent callchain data collection with hardware sampling, since the
         callchains simply do not exist
      
       - Prevent multiple registrations of the same zPCI function
      
       - Update defconfigs
      
      * tag 's390-5.8-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        vfio-ccw: Fix a build error due to missing include of linux/slab.h
        s390: update defconfigs
        s390/cpum_sf: prohibit callchain data collection
        s390/setup: init jump labels before command line parsing
        s390/maccess: add no DAT mode to kernel_write
        s390/pci: fix enabling a reserved PCI function
      5c82ec00
    • P
      Merge tag 'kvmarm-fixes-5.8-3' of... · 8038a922
      Paolo Bonzini 提交于
      Merge tag 'kvmarm-fixes-5.8-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master
      
      KVM/arm fixes for 5.8, take #3
      
      - Disable preemption on context-switching PMU EL0 state happening
        on system register trap
      - Don't clobber X0 when tearing down KVM via a soft reset (kexec)
      8038a922
  4. 06 7月, 2020 26 次提交