1. 16 10月, 2018 3 次提交
    • J
      perf tools: Fix tracing_path_mount proper path · c458a620
      Jiri Olsa 提交于
      If there's no tracefs (RHEL7) support the tracing_path_mount
      returns debugfs path which results in following fail:
      
        # perf probe sys_write
        kprobe_events file does not exist - please rebuild kernel with CONFIG_KPROBE_EVENTS.
        Error: Failed to add events.
      
      In tracing_path_debugfs_mount function we need to return the
      'tracing' path instead of just the mount to make it work:
      
        # perf probe sys_write
        Added new event:
          probe:sys_write      (on sys_write)
      
        You can now use it in all perf tools, such as:
      
                perf record -e probe:sys_write -aR sleep 1
      
      Adding the 'return tracing_path;' also to tracing_path_tracefs_mount
      function just for consistency with tracing_path_debugfs_mount.
      
      Upstream keeps working, because it has the tracefs support.
      
      Link: http://lkml.kernel.org/n/tip-yiwkzexq9fk1ey1xg3gnjlw4@git.kernel.orgSigned-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Fixes: 23773ca1 ("perf tools: Make perf aware of tracefs")
      Link: http://lkml.kernel.org/r/20181016114818.3595-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c458a620
    • J
      perf tools: Fix use of alternatives to find JDIR · 36b8d462
      Jarod Wilson 提交于
      When a build is run from something like a cron job, the user's $PATH is
      rather minimal, of note, not including /usr/sbin in my own case. Because
      of that, an automated rpm package build ultimately fails to find
      libperf-jvmti.so, because somewhere within the build, this happens...
      
        /bin/sh: alternatives: command not found
        /bin/sh: alternatives: command not found
        Makefile.config:849: No openjdk development package found, please install
        JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel
      
      ...and while the build continues, libperf-jvmti.so isn't built, and
      things fall down when rpm tries to find all the %files specified. Exact
      same system builds everything just fine when the job is launched from a
      login shell instead of a cron job, since alternatives is in $PATH, so
      openjdk is actually found.
      
      The test required to get into this section of code actually specifies
      the full path, as does a block just above it, so let's do that here too.
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: William Cohen <wcohen@redhat.com>
      Fixes: d4dfdf00 ("perf jvmti: Plug compilation into perf build")
      Link: http://lkml.kernel.org/r/20180906221812.11167-1-jarod@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      36b8d462
    • J
      perf evsel: Store ids for events with their own cpus perf_event__synthesize_event_update_cpus · 4ab8455f
      Jiri Olsa 提交于
      John reported crash when recording on an event under PMU with cpumask defined:
      
        root@localhost:~# ./perf_debug_ record -e armv8_pmuv3_0/br_mis_pred/ sleep 1
        perf: Segmentation fault
        Obtained 9 stack frames.
        ./perf_debug_() [0x4c5ef8]
        [0xffff82ba267c]
        ./perf_debug_() [0x4bc5a8]
        ./perf_debug_() [0x419550]
        ./perf_debug_() [0x41a928]
        ./perf_debug_() [0x472f58]
        ./perf_debug_() [0x473210]
        ./perf_debug_() [0x4070f4]
        /lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0xe0) [0xffff8294c8a0]
        Segmentation fault (core dumped)
      
      We synthesize an update event that needs to touch the evsel id array, which is
      not defined at that time. Fixing this by forcing the id allocation for events
      with their own cpus.
      Reported-by: NJohn Garry <john.garry@huawei.com>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NJohn Garry <john.garry@huawei.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linuxarm@huawei.com
      Fixes: bfd8f72c ("perf record: Synthesize unit/scale/... in event update")
      Link: http://lkml.kernel.org/r/20181003212052.GA32371@kravaSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4ab8455f
  2. 11 10月, 2018 1 次提交
    • J
      perf vendor events intel: Fix wrong filter_band* values for uncore events · 94aafb74
      Jiri Olsa 提交于
      Michael reported that he could not stat following event:
      
        $ perf stat -e unc_p_freq_ge_1200mhz_cycles -a -- ls
        event syntax error: '..e_1200mhz_cycles'
                                          \___ value too big for format, maximum is 255
        Run 'perf list' for a list of valid events
      
      The event is unwrapped into:
      
        uncore_pcu/event=0xb,filter_band0=1200/
      
      where filter_band0 format says it's one byte only:
      
        # cat uncore_pcu/format/filter_band0
        config1:0-7
      
      while JSON files specifies bigger number:
      
        "Filter": "filter_band0=1200",
      
      all the filter_band* formats show 1 byte width:
      
        # cat uncore_pcu/format/filter_band1
        config1:8-15
        # cat uncore_pcu/format/filter_band2
        config1:16-23
        # cat uncore_pcu/format/filter_band3
        config1:24-31
      
      The reason of the issue is that filter_band* values are supposed to be
      in 100Mhz units.. it's stated in the JSON help for the events, like:
      
        filter_band3=XXX, with XXX in 100Mhz units
      
      This patch divides the filter_band* values by 100, plus there's couple
      of changes that actually change the number completely, like:
      
        -        "Filter": "edge=1,filter_band2=4000",
        +        "Filter": "edge=1,filter_band2=30",
      Reported-by: NMichael Petlan <mpetlan@redhat.com>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Acked-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20181010080339.GB15790@kravaSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      94aafb74
  3. 09 10月, 2018 1 次提交
    • J
      Revert "perf tools: Fix PMU term format max value calculation" · 1b9caa10
      Jiri Olsa 提交于
      This reverts commit ac0e2cd5.
      
      Michael reported an issue with oversized terms values assignment
      and I noticed there was actually a misunderstanding of the max
      value check in the past.
      
      The above commit's changelog says:
      
        If bit 21 is set, there is parsing issues as below.
      
          $ perf stat -a -e uncore_qpi_0/event=0x200002,umask=0x8/
          event syntax error: '..pi_0/event=0x200002,umask=0x8/'
                                            \___ value too big for format, maximum is 511
      
      But there's no issue there, because the event value is distributed
      along the value defined by the format. Even if the format defines
      separated bit, the value is treated as a continual number, which
      should follow the format definition.
      
      In above case it's 9-bit value with last bit separated:
        $ cat uncore_qpi_0/format/event
        config:0-7,21
      
      Hence the value 0x200002 is correctly reported as format violation,
      because it exceeds 9 bits. It should have been 0x102 instead, which
      sets the 9th bit - the bit 21 of the format.
      
        $ perf stat -vv -a -e uncore_qpi_0/event=0x102,umask=0x8/
        Using CPUID GenuineIntel-6-2D
        ...
        ------------------------------------------------------------
        perf_event_attr:
          type                             10
          size                             112
          config                           0x200802
          sample_type                      IDENTIFIER
        ...
      Reported-by: NMichael Petlan <mpetlan@redhat.com>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: ac0e2cd5 ("perf tools: Fix PMU term format max value calculation")
      Link: http://lkml.kernel.org/r/20181003072046.29276-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1b9caa10
  4. 08 10月, 2018 2 次提交
    • A
      tools headers uapi: Sync kvm.h copy · 25fe15e5
      Arnaldo Carvalho de Melo 提交于
      To pick up the changes introduced in:
      
        6fbbde9a ("KVM: x86: Control guest reads of MSR_PLATFORM_INFO")
      
      That is not yet used in tools such as 'perf trace'.
      
      The type of the change in this file, a simple integer parameter to the
      KVM_CHECK_EXTENSION ioctl should be easier to implement tho, adding to
      the libbeauty TODO list.
      
      This silences this perf build warning:
      
        Warning: Kernel ABI header at 'tools/include/uapi/linux/kvm.h' differs from latest version at 'include/uapi/linux/kvm.h'
        diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Drew Schmitt <dasch@google.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-67h1bio5bihi1q6dy7hgwwx8@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      25fe15e5
    • A
      tools arch uapi: Sync the x86 kvm.h copy · 4312f2ab
      Arnaldo Carvalho de Melo 提交于
      To get the changes in:
      
        d1766202 ("x86/kvm/lapic: always disable MMIO interface in x2APIC mode")
      
      That at this time will not generate changes in tools such as 'perf trace',
      that still needs more work in tools/perf/examples/bpf/augmented_syscalls.c
      to need such id -> string tables.
      
      This silences the following perf build warning:
      
        Warning: Kernel ABI header at 'tools/arch/x86/include/uapi/asm/kvm.h' differs from latest version at 'arch/x86/include/uapi/asm/kvm.h'
        diff -u tools/arch/x86/include/uapi/asm/kvm.h arch/x86/include/uapi/asm/kvm.h
      
      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: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-yadntj2ok6zpzjwi656onuh0@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4312f2ab
  5. 06 10月, 2018 1 次提交
    • I
      Merge tag 'perf-urgent-for-mingo-4.19-20181005' of... · c1883f10
      Ingo Molnar 提交于
      Merge tag 'perf-urgent-for-mingo-4.19-20181005' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent
      
      Pull perf/urgent fixes from Arnaldo Carvalho de Melo:
      
      - Fix the build on Clear Linux, coping with redundant declarations of
        function prototypes in python3 header files by adding
        -Wno-redundant-decls to build with PYTHON=python3 (Arnaldo Carvalho de Melo)
      
      - Fixes for processing inline frames in backtraces using DWARF based
        unwinding (Milian Wolff)
      
      - Cope with bad DWARF info for function names for inline frames,not
        trying to demangle this symbol. Problem reported with rust but
        reproduced as well with C++. Problem reported to the libbpf
        maintainers (Milian Wolff)
      
      - Fix python export to postgresql and sqlite code (Adrian Hunter)
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      c1883f10
  6. 05 10月, 2018 2 次提交
    • M
      perf record: Use unmapped IP for inline callchain cursors · 7a8a8fcf
      Milian Wolff 提交于
      Only use the mapped IP to find inline frames, but keep using the
      unmapped IP for the callchain cursor. This ensures we properly show the
      unmapped IP when displaying a frame we received via the
      dso__parse_addr_inlines API for a module which does not contain
      sufficient debug symbols to show the srcline.
      
      This is another follow-up to commit 19610184 ("perf script: Show
      virtual addresses instead of offsets").
      Signed-off-by: NMilian Wolff <milian.wolff@kdab.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NRavi Bangoria <ravi.bangoria@linux.ibm.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Sandipan Das <sandipan@linux.ibm.com>
      Fixes: 19610184 ("perf script: Show virtual addresses instead of offsets")
      Link: http://lkml.kernel.org/r/20180926135207.30263-2-milian.wolff@kdab.com
      Link: http://lkml.kernel.org/r/20181002073949.3297-1-milian.wolff@kdab.com
      [ Squashed a fix from Milian for a problem reported by Ravi, fixed up space damage ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7a8a8fcf
    • A
      perf python: Use -Wno-redundant-decls to build with PYTHON=python3 · 05a2f546
      Arnaldo Carvalho de Melo 提交于
      When building in ClearLinux using 'make PYTHON=python3' with gcc 8.2.1
      it fails with:
      
          GEN      /tmp/build/perf/python/perf.so
        In file included from /usr/include/python3.7m/Python.h:126,
                         from /git/linux/tools/perf/util/python.c:2:
        /usr/include/python3.7m/import.h:58:24: error: redundant redeclaration of ‘_PyImport_AddModuleObject’ [-Werror=redundant-decls]
         PyAPI_FUNC(PyObject *) _PyImport_AddModuleObject(PyObject *, PyObject *);
                                ^~~~~~~~~~~~~~~~~~~~~~~~~
        /usr/include/python3.7m/import.h:47:24: note: previous declaration of ‘_PyImport_AddModuleObject’ was here
         PyAPI_FUNC(PyObject *) _PyImport_AddModuleObject(PyObject *name,
                                ^~~~~~~~~~~~~~~~~~~~~~~~~
        cc1: all warnings being treated as errors
        error: command 'gcc' failed with exit status 1
      
      And indeed there is a redundant declaration in that Python.h file, one
      with parameter names and the other without, so just add
      -Wno-error=redundant-decls to the python setup instructions.
      
      Now perf builds with gcc in ClearLinux with the following Dockerfile:
      
        # docker.io/acmel/linux-perf-tools-build-clearlinux:latest
        FROM docker.io/clearlinux:latest
        MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
        RUN swupd update && \
            swupd bundle-add sysadmin-basic-dev
        RUN mkdir -m 777 -p /git /tmp/build/perf /tmp/build/objtool /tmp/build/linux && \
            groupadd -r perfbuilder && \
            useradd -m -r -g perfbuilder perfbuilder && \
            chown -R perfbuilder.perfbuilder /tmp/build/ /git/
        USER perfbuilder
        COPY rx_and_build.sh /
        ENV EXTRA_MAKE_ARGS=PYTHON=python3
        ENTRYPOINT ["/rx_and_build.sh"]
      
      Now to figure out why the build fails with clang, that is present in the
      above container as detected by the rx_and_build.sh script:
      
        clang version 6.0.1 (tags/RELEASE_601/final)
        Target: x86_64-unknown-linux-gnu
        Thread model: posix
        InstalledDir: /usr/sbin
        make: Entering directory '/git/linux/tools/perf'
          BUILD:   Doing 'make -j4' parallel build
          HOSTCC   /tmp/build/perf/fixdep.o
          HOSTLD   /tmp/build/perf/fixdep-in.o
          LINK     /tmp/build/perf/fixdep
      
        Auto-detecting system features:
        ...                         dwarf: [ OFF ]
        ...            dwarf_getlocations: [ OFF ]
        ...                         glibc: [ OFF ]
        ...                          gtk2: [ OFF ]
        ...                      libaudit: [ OFF ]
        ...                        libbfd: [ OFF ]
        ...                        libelf: [ OFF ]
        ...                       libnuma: [ OFF ]
        ...        numa_num_possible_cpus: [ OFF ]
        ...                       libperl: [ OFF ]
        ...                     libpython: [ OFF ]
        ...                      libslang: [ OFF ]
        ...                     libcrypto: [ OFF ]
        ...                     libunwind: [ OFF ]
        ...            libdw-dwarf-unwind: [ OFF ]
        ...                          zlib: [ OFF ]
        ...                          lzma: [ OFF ]
        ...                     get_cpuid: [ OFF ]
        ...                           bpf: [ OFF ]
      
        Makefile.config:331: *** No gnu/libc-version.h found, please install glibc-dev[el].  Stop.
        make[1]: *** [Makefile.perf:206: sub-make] Error 2
        make: *** [Makefile:70: all] Error 2
        make: Leaving directory '/git/linux/tools/perf'
      
      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: Thiago Macieira <thiago.macieira@intel.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-c3khb9ac86s00qxzjrueomme@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      05a2f546
  7. 02 10月, 2018 5 次提交
    • N
      perf/x86/amd/uncore: Set ThreadMask and SliceMask for L3 Cache perf events · d7cbbe49
      Natarajan, Janakarajan 提交于
      In Family 17h, some L3 Cache Performance events require the ThreadMask
      and SliceMask to be set. For other events, these fields do not affect
      the count either way.
      
      Set ThreadMask and SliceMask to 0xFF and 0xF respectively.
      Signed-off-by: NJanakarajan Natarajan <Janakarajan.Natarajan@amd.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H . Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Suravee <Suravee.Suthikulpanit@amd.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/Message-ID:
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      d7cbbe49
    • K
      perf/x86/intel/uncore: Fix PCI BDF address of M3UPI on SKX · 9d92cfea
      Kan Liang 提交于
      The counters on M3UPI Link 0 and Link 3 don't count properly, and writing
      0 to these counters may causes system crash on some machines.
      
      The PCI BDF addresses of the M3UPI in the current code are incorrect.
      
      The correct addresses should be:
      
        D18:F1	0x204D
        D18:F2	0x204E
        D18:F5	0x204D
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Fixes: cd34cd97 ("perf/x86/intel/uncore: Add Skylake server uncore support")
      Link: http://lkml.kernel.org/r/1537538826-55489-1-git-send-email-kan.liang@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9d92cfea
    • J
      perf/ring_buffer: Prevent concurent ring buffer access · cd6fb677
      Jiri Olsa 提交于
      Some of the scheduling tracepoints allow the perf_tp_event
      code to write to ring buffer under different cpu than the
      code is running on.
      
      This results in corrupted ring buffer data demonstrated in
      following perf commands:
      
        # perf record -e 'sched:sched_switch,sched:sched_wakeup' perf bench sched messaging
        # Running 'sched/messaging' benchmark:
        # 20 sender and receiver processes per group
        # 10 groups == 400 processes run
      
             Total time: 0.383 [sec]
        [ perf record: Woken up 8 times to write data ]
        0x42b890 [0]: failed to process type: -1765585640
        [ perf record: Captured and wrote 4.825 MB perf.data (29669 samples) ]
      
        # perf report --stdio
        0x42b890 [0]: failed to process type: -1765585640
      
      The reason for the corruption are some of the scheduling tracepoints,
      that have __perf_task dfined and thus allow to store data to another
      cpu ring buffer:
      
        sched_waking
        sched_wakeup
        sched_wakeup_new
        sched_stat_wait
        sched_stat_sleep
        sched_stat_iowait
        sched_stat_blocked
      
      The perf_tp_event function first store samples for current cpu
      related events defined for tracepoint:
      
          hlist_for_each_entry_rcu(event, head, hlist_entry)
            perf_swevent_event(event, count, &data, regs);
      
      And then iterates events of the 'task' and store the sample
      for any task's event that passes tracepoint checks:
      
        ctx = rcu_dereference(task->perf_event_ctxp[perf_sw_context]);
      
        list_for_each_entry_rcu(event, &ctx->event_list, event_entry) {
          if (event->attr.type != PERF_TYPE_TRACEPOINT)
            continue;
          if (event->attr.config != entry->type)
            continue;
      
          perf_swevent_event(event, count, &data, regs);
        }
      
      Above code can race with same code running on another cpu,
      ending up with 2 cpus trying to store under the same ring
      buffer, which is specifically not allowed.
      
      This patch prevents the problem, by allowing only events with the same
      current cpu to receive the event.
      
      NOTE: this requires the use of (per-task-)per-cpu buffers for this
      feature to work; perf-record does this.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      [peterz: small edits to Changelog]
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andrew Vagin <avagin@openvz.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Fixes: e6dab5ff ("perf/trace: Add ability to set a target task for events")
      Link: http://lkml.kernel.org/r/20180923161343.GB15054@kravaSigned-off-by: NIngo Molnar <mingo@kernel.org>
      cd6fb677
    • M
      perf/x86/intel/uncore: Use boot_cpu_data.phys_proc_id instead of hardcorded physical package ID 0 · 6265adb9
      Masayoshi Mizuma 提交于
      Physical package id 0 doesn't always exist, we should use
      boot_cpu_data.phys_proc_id here.
      Signed-off-by: NMasayoshi Mizuma <m.mizuma@jp.fujitsu.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masayoshi Mizuma <msys.mizuma@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Link: http://lkml.kernel.org/r/20180910144750.6782-1-msys.mizuma@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6265adb9
    • P
      perf/core: Fix perf_pmu_unregister() locking · a9f97721
      Peter Zijlstra 提交于
      When we unregister a PMU, we fail to serialize the @pmu_idr properly.
      Fix that by doing the entire thing under pmu_lock.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Fixes: 2e80a82a ("perf: Dynamic pmu types")
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      a9f97721
  8. 30 9月, 2018 4 次提交
    • G
      Merge tag 'for-linus-20180929' of git://git.kernel.dk/linux-block · 291d0e5d
      Greg Kroah-Hartman 提交于
      Jens writes:
        "Block fixes for 4.19-rc6
      
         A set of fixes that should go into this release. This pull request
         contains:
      
         - A fix (hopefully) for the persistent grants for xen-blkfront. A
           previous fix from this series wasn't complete, hence reverted, and
           this one should hopefully be it. (Boris Ostrovsky)
      
         - Fix for an elevator drain warning with SMR devices, which is
           triggered when you switch schedulers (Damien)
      
         - bcache deadlock fix (Guoju Fang)
      
         - Fix for the block unplug tracepoint, which has had the
           timer/explicit flag reverted since 4.11 (Ilya)
      
         - Fix a regression in this series where the blk-mq timeout hook is
           invoked with the RCU read lock held, hence preventing it from
           blocking (Keith)
      
         - NVMe pull from Christoph, with a single multipath fix (Susobhan Dey)"
      
      * tag 'for-linus-20180929' of git://git.kernel.dk/linux-block:
        xen/blkfront: correct purging of persistent grants
        Revert "xen/blkfront: When purging persistent grants, keep them in the buffer"
        blk-mq: I/O and timer unplugs are inverted in blktrace
        bcache: add separate workqueue for journal_write to avoid deadlock
        xen/blkfront: When purging persistent grants, keep them in the buffer
        block: fix deadline elevator drain for zoned block devices
        blk-mq: Allow blocking queue tag iter callbacks
        nvme: properly propagate errors in nvme_mpath_init
      291d0e5d
    • G
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · e7541773
      Greg Kroah-Hartman 提交于
      Thomas writes:
        "A single fix for the AMD memory encryption boot code so it does not
         read random garbage instead of the cached encryption bit when a kexec
         kernel is allocated above the 32bit address limit."
      
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/boot: Fix kexec booting failure in the SEV bit detection code
      e7541773
    • G
      Merge branch 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · e1ce697d
      Greg Kroah-Hartman 提交于
      Thomas writes:
        "Three small fixes for clocksource drivers:
         - Proper error handling in the Atmel PIT driver
         - Add CLOCK_SOURCE_SUSPEND_NONSTOP for TI SoCs so suspend works again
         - Fix the next event function for Facebook Backpack-CMM BMC chips so
           usleep(100) doesnt sleep several milliseconds"
      
      * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        clocksource/drivers/timer-atmel-pit: Properly handle error cases
        clocksource/drivers/fttmr010: Fix set_next_event handler
        clocksource/drivers/ti-32k: Add CLOCK_SOURCE_SUSPEND_NONSTOP flag for non-am43 SoCs
      e1ce697d
    • G
      Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · af17b3aa
      Greg Kroah-Hartman 提交于
      Thomas writes:
        "A single fix for a missing sanity check when a pinned event is tried
        to be read on the wrong CPU due to a legit event scheduling failure."
      
      * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        perf/core: Add sanity check to deal with pinned event failure
      af17b3aa
  9. 29 9月, 2018 12 次提交
  10. 28 9月, 2018 9 次提交