1. 10 Jul, 2020 1 commit
  2. 09 Jul, 2020 1 commit
    • Numfor Mbiziwo-Tiapo's avatar
      perf annotate: Fix non-null terminated buffer returned by readlink() · b39730a6
      Numfor Mbiziwo-Tiapo authored
      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: default avatarNumfor Mbiziwo-Tiapo <nums@google.com>
      Acked-by: default avatarIan Rogers <irogers@google.com>
      Acked-by: default avatarJiri 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: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      b39730a6
  3. 08 Jul, 2020 2 commits
    • Steve MacLean's avatar
      perf inject jit: Remove //anon mmap events · c8f6ae1f
      Steve MacLean authored
      **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: default avatarSteve MacLean <Steve.MacLean@Microsoft.com>
      Acked-by: default avatarIan 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: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      c8f6ae1f
    • Arnaldo Carvalho de Melo's avatar
      Merge remote-tracking branch 'torvalds/master' into perf/core · facbf0b9
      Arnaldo Carvalho de Melo authored
      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: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      facbf0b9
  4. 07 Jul, 2020 8 commits
  5. 06 Jul, 2020 24 commits
  6. 05 Jul, 2020 4 commits
    • Linus Torvalds's avatar
      Linux 5.8-rc4 · dcb7fd82
      Linus Torvalds authored
      dcb7fd82
    • Linus Torvalds's avatar
      x86/ldt: use "pr_info_once()" instead of open-coding it badly · bb5a93aa
      Linus Torvalds authored
      Using a mutex for "print this warning only once" is so overdesigned as
      to be actively offensive to my sensitive stomach.
      
      Just use "pr_info_once()" that already does this, although in a
      (harmlessly) racy manner that can in theory cause the message to be
      printed twice if more than one CPU races on that "is this the first
      time" test.
      
      [ If somebody really cares about that harmless data race (which sounds
        very unlikely indeed), that person can trivially fix printk_once() by
        using a simple atomic access, preferably with an optimistic non-atomic
        test first before even bothering to treat the pointless "make sure it
        is _really_ just once" case.
      
        A mutex is most definitely never the right primitive to use for
        something like this. ]
      
      Yes, this is a small and meaningless detail in a code path that hardly
      matters.  But let's keep some code quality standards here, and not
      accept outrageously bad code.
      
      Link: https://lore.kernel.org/lkml/CAHk-=wgV9toS7GU3KmNpj8hCS9SeF+A0voHS8F275_mgLhL4Lw@mail.gmail.com/
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bb5a93aa
    • Linus Torvalds's avatar
      Merge tag 'x86-urgent-2020-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 72674d48
      Linus Torvalds authored
      Pull x86 fixes from Thomas Gleixner:
       "A series of fixes for x86:
      
         - Reset MXCSR in kernel_fpu_begin() to prevent using a stale user
           space value.
      
         - Prevent writing MSR_TEST_CTRL on CPUs which are not explicitly
           whitelisted for split lock detection. Some CPUs which do not
           support it crash even when the MSR is written to 0 which is the
           default value.
      
         - Fix the XEN PV fallout of the entry code rework
      
         - Fix the 32bit fallout of the entry code rework
      
         - Add more selftests to ensure that these entry problems don't come
           back.
      
         - Disable 16 bit segments on XEN PV. It's not supported because XEN
           PV does not implement ESPFIX64"
      
      * tag 'x86-urgent-2020-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/ldt: Disable 16-bit segments on Xen PV
        x86/entry/32: Fix #MC and #DB wiring on x86_32
        x86/entry/xen: Route #DB correctly on Xen PV
        x86/entry, selftests: Further improve user entry sanity checks
        x86/entry/compat: Clear RAX high bits on Xen PV SYSENTER
        selftests/x86: Consolidate and fix get/set_eflags() helpers
        selftests/x86/syscall_nt: Clear weird flags after each test
        selftests/x86/syscall_nt: Add more flag combinations
        x86/entry/64/compat: Fix Xen PV SYSENTER frame setup
        x86/entry: Move SYSENTER's regs->sp and regs->flags fixups into C
        x86/entry: Assert that syscalls are on the right stack
        x86/split_lock: Don't write MSR_TEST_CTRL on CPUs that aren't whitelisted
        x86/fpu: Reset MXCSR to default in kernel_fpu_begin()
      72674d48
    • Linus Torvalds's avatar
      Merge tag 'irq-urgent-2020-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · f23dbe18
      Linus Torvalds authored
      Pull irq fixes from Thomas Gleixner:
       "A set of interrupt chip driver fixes:
      
         - Ensure the atomicity of affinity updates in the GIC driver
      
         - Don't try to sleep in atomic context when waiting for the GICv4.1
           to respond. Use polling instead.
      
         - Typo fixes in Kconfig and warnings"
      
      * tag 'irq-urgent-2020-07-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        irqchip/gic: Atomically update affinity
        irqchip/riscv-intc: Fix a typo in a pr_warn()
        irqchip/gic-v4.1: Use readx_poll_timeout_atomic() to fix sleep in atomic
        irqchip/loongson-pci-msi: Fix a typo in Kconfig
      f23dbe18