1. 07 8月, 2019 2 次提交
  2. 31 7月, 2019 7 次提交
    • L
      perf hists browser: Fix potential NULL pointer dereference found by the smatch tool · 4fe7ea29
      Leo Yan 提交于
      [ Upstream commit ceb75476db1617a88cc29b09839acacb69aa076e ]
      
      Based on the following report from Smatch, fix the potential
      NULL pointer dereference check.
      
        tools/perf/ui/browsers/hists.c:641
        hist_browser__run() error: we previously assumed 'hbt' could be
        null (see line 625)
      
        tools/perf/ui/browsers/hists.c:3088
        perf_evsel__hists_browse() error: we previously assumed
        'browser->he_selection' could be null (see line 2902)
      
        tools/perf/ui/browsers/hists.c:3272
        perf_evsel_menu__run() error: we previously assumed 'hbt' could be
        null (see line 3260)
      
      This patch firstly validating the pointers before access them, so can
      fix potential NULL pointer dereference.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20190708143937.7722-2-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4fe7ea29
    • L
      perf annotate: Fix dereferencing freed memory found by the smatch tool · 915945f3
      Leo Yan 提交于
      [ Upstream commit 600c787dbf6521d8d07ee717ab7606d5070103ea ]
      
      Based on the following report from Smatch, fix the potential
      dereferencing freed memory check.
      
        tools/perf/util/annotate.c:1125
        disasm_line__parse() error: dereferencing freed memory 'namep'
      
        tools/perf/util/annotate.c
        1100 static int disasm_line__parse(char *line, const char **namep, char **rawp)
        1101 {
        1102         char tmp, *name = ltrim(line);
      
        [...]
      
        1114         *namep = strdup(name);
        1115
        1116         if (*namep == NULL)
        1117                 goto out_free_name;
      
        [...]
      
        1124 out_free_name:
        1125         free((void *)namep);
                                  ^^^^^
        1126         *namep = NULL;
                     ^^^^^^
        1127         return -1;
        1128 }
      
      If strdup() fails to allocate memory space for *namep, we don't need to
      free memory with pointer 'namep', which is resident in data structure
      disasm_line::ins::name; and *namep is NULL pointer for this failure, so
      it's pointless to assign NULL to *namep again.
      
      Committer note:
      
      Freeing namep, which is the address of the first entry of the 'struct
      ins' that is the first member of struct disasm_line would in fact free
      that disasm_line instance, if it was allocated via malloc/calloc, which,
      later, would a dereference of freed memory.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Alexios Zavras <alexios.zavras@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Changbin Du <changbin.du@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20190702103420.27540-5-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      915945f3
    • L
      perf session: Fix potential NULL pointer dereference found by the smatch tool · b305dcff
      Leo Yan 提交于
      [ Upstream commit f3c8d90757724982e5f07cd77d315eb64ca145ac ]
      
      Based on the following report from Smatch, fix the potential
      NULL pointer dereference check.
      
        tools/perf/util/session.c:1252
        dump_read() error: we previously assumed 'evsel' could be null
        (see line 1249)
      
        tools/perf/util/session.c
        1240 static void dump_read(struct perf_evsel *evsel, union perf_event *event)
        1241 {
        1242         struct read_event *read_event = &event->read;
        1243         u64 read_format;
        1244
        1245         if (!dump_trace)
        1246                 return;
        1247
        1248         printf(": %d %d %s %" PRIu64 "\n", event->read.pid, event->read.tid,
        1249                evsel ? perf_evsel__name(evsel) : "FAIL",
        1250                event->read.value);
        1251
        1252         read_format = evsel->attr.read_format;
                                   ^^^^^^^
      
      'evsel' could be NULL pointer, for this case this patch directly bails
      out without dumping read_event.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Alexios Zavras <alexios.zavras@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Changbin Du <changbin.du@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20190702103420.27540-9-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b305dcff
    • L
      perf top: Fix potential NULL pointer dereference detected by the smatch tool · 19cf571c
      Leo Yan 提交于
      [ Upstream commit 111442cfc8abdeaa7ec1407f07ef7b3e5f76654e ]
      
      Based on the following report from Smatch, fix the potential NULL
      pointer dereference check.
      
        tools/perf/builtin-top.c:109
        perf_top__parse_source() warn: variable dereferenced before check 'he'
        (see line 103)
      
        tools/perf/builtin-top.c:233
        perf_top__show_details() warn: variable dereferenced before check 'he'
        (see line 228)
      
        tools/perf/builtin-top.c
        101 static int perf_top__parse_source(struct perf_top *top, struct hist_entry *he)
        102 {
        103         struct perf_evsel *evsel = hists_to_evsel(he->hists);
                                                              ^^^^
        104         struct symbol *sym;
        105         struct annotation *notes;
        106         struct map *map;
        107         int err = -1;
        108
        109         if (!he || !he->ms.sym)
        110                 return -1;
      
      This patch moves the values assignment after validating pointer 'he'.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Alexios Zavras <alexios.zavras@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Changbin Du <changbin.du@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20190702103420.27540-4-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      19cf571c
    • L
      perf stat: Fix use-after-freed pointer detected by the smatch tool · 995527db
      Leo Yan 提交于
      [ Upstream commit c74b05030edb3b52f4208d8415b8c933bc509a29 ]
      
      Based on the following report from Smatch, fix the use-after-freed
      pointer.
      
        tools/perf/builtin-stat.c:1353
        add_default_attributes() warn: passing freed memory 'str'.
      
      The pointer 'str' has been freed but later it is still passed into the
      function parse_events_print_error().  This patch fixes this
      use-after-freed issue.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Alexios Zavras <alexios.zavras@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Changbin Du <changbin.du@intel.com>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Link: http://lkml.kernel.org/r/20190702103420.27540-3-leo.yan@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      995527db
    • N
      perf test mmap-thread-lookup: Initialize variable to suppress memory sanitizer warning · 3b8c4eae
      Numfor Mbiziwo-Tiapo 提交于
      [ Upstream commit 4e4cf62b37da5ff45c904a3acf242ab29ed5881d ]
      
      Running the 'perf test' command after building perf with a memory
      sanitizer causes a warning that says:
      
        WARNING: MemorySanitizer: use-of-uninitialized-value... in mmap-thread-lookup.c
      
      Initializing the go variable to 0 silences this harmless warning.
      
      Committer warning:
      
      This was harmless, just a simple test writing whatever was at that
      sizeof(int) memory area just to signal another thread blocked reading
      that file created with pipe(). Initialize it tho so that we don't get
      this warning.
      Signed-off-by: NNumfor Mbiziwo-Tiapo <nums@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ian Rogers <irogers@google.com>
      Cc: Jiri Olsa <jolsa@redhat.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://lkml.kernel.org/r/20190702173716.181223-1-nums@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3b8c4eae
    • B
      iio: iio-utils: Fix possible incorrect mask calculation · b150423e
      Bastien Nocera 提交于
      [ Upstream commit 208a68c8393d6041a90862992222f3d7943d44d6 ]
      
      On some machines, iio-sensor-proxy was returning all 0's for IIO sensor
      values. It turns out that the bits_used for this sensor is 32, which makes
      the mask calculation:
      
      *mask = (1 << 32) - 1;
      
      If the compiler interprets the 1 literals as 32-bit ints, it generates
      undefined behavior depending on compiler version and optimization level.
      On my system, it optimizes out the shift, so the mask value becomes
      
      *mask = (1) - 1;
      
      With a mask value of 0, iio-sensor-proxy will always return 0 for every axis.
      
      Avoid incorrect 0 values caused by compiler optimization.
      
      See original fix by Brett Dutro <brett.dutro@gmail.com> in
      iio-sensor-proxy:
      https://github.com/hadess/iio-sensor-proxy/commit/9615ceac7c134d838660e209726cd86aa2064fd3Signed-off-by: NBastien Nocera <hadess@hadess.net>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b150423e
  3. 26 7月, 2019 15 次提交
    • S
      perf tests: Fix record+probe_libc_inet_pton.sh for powerpc64 · 3b57b7a3
      Seeteena Thoufeek 提交于
      [ Upstream commit bff5a556c149804de29347a88a884d25e4e4e3a2 ]
      
      'probe libc's inet_pton & backtrace it with ping' testcase sometimes
      fails on powerpc because distro ping binary does not have symbol
      information and thus it prints "[unknown]" function name in the
      backtrace.
      
      Accept "[unknown]" as valid function name for powerpc as well.
      
       # perf test -v "probe libc's inet_pton & backtrace it with ping"
      
      Before:
      
        59: probe libc's inet_pton & backtrace it with ping       :
        --- start ---
        test child forked, pid 79695
        ping 79718 [077] 96483.787025: probe_libc:inet_pton: (7fff83a754c8)
        7fff83a754c8 __GI___inet_pton+0x8 (/usr/lib64/power9/libc-2.28.so)
        7fff83a2b7a0 gaih_inet.constprop.7+0x1020
        (/usr/lib64/power9/libc-2.28.so)
        7fff83a2c170 getaddrinfo+0x160 (/usr/lib64/power9/libc-2.28.so)
        1171830f4 [unknown] (/usr/bin/ping)
        FAIL: expected backtrace entry
        ".*\+0x[[:xdigit:]]+[[:space:]]\(.*/bin/ping.*\)$"
        got "1171830f4 [unknown] (/usr/bin/ping)"
        test child finished with -1
        ---- end ----
        probe libc's inet_pton & backtrace it with ping: FAILED!
      
      After:
      
        59: probe libc's inet_pton & backtrace it with ping       :
        --- start ---
        test child forked, pid 79085
        ping 79108 [045] 96400.214177: probe_libc:inet_pton: (7fffbb9654c8)
        7fffbb9654c8 __GI___inet_pton+0x8 (/usr/lib64/power9/libc-2.28.so)
        7fffbb91b7a0 gaih_inet.constprop.7+0x1020
        (/usr/lib64/power9/libc-2.28.so)
        7fffbb91c170 getaddrinfo+0x160 (/usr/lib64/power9/libc-2.28.so)
        132e830f4 [unknown] (/usr/bin/ping)
        test child finished with 0
        ---- end ----
        probe libc's inet_pton & backtrace it with ping: Ok
      Signed-off-by: NSeeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
      Reviewed-by: NKim Phillips <kim.phillips@amd.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sandipan Das <sandipan@linux.ibm.com>
      Fixes: 1632936480a5 ("perf tests: Fix record+probe_libc_inet_pton.sh without ping's debuginfo")
      Link: http://lkml.kernel.org/r/1561630614-3216-1-git-send-email-s1seetee@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3b57b7a3
    • J
      tools: bpftool: Fix json dump crash on powerpc · 9d47bd21
      Jiri Olsa 提交于
      [ Upstream commit aa52bcbe0e72fac36b1862db08b9c09c4caefae3 ]
      
      Michael reported crash with by bpf program in json mode on powerpc:
      
        # bpftool prog -p dump jited id 14
        [{
              "name": "0xd00000000a9aa760",
              "insns": [{
                      "pc": "0x0",
                      "operation": "nop",
                      "operands": [null
                      ]
                  },{
                      "pc": "0x4",
                      "operation": "nop",
                      "operands": [null
                      ]
                  },{
                      "pc": "0x8",
                      "operation": "mflr",
        Segmentation fault (core dumped)
      
      The code is assuming char pointers in format, which is not always
      true at least for powerpc. Fixing this by dumping the whole string
      into buffer based on its format.
      
      Please note that libopcodes code does not check return values from
      fprintf callback, but as per Jakub suggestion returning -1 on allocation
      failure so we do the best effort to propagate the error.
      
      Fixes: 107f0412 ("tools: bpftool: add JSON output for `bpftool prog dump jited *` command")
      Reported-by: NMichael Petlan <mpetlan@redhat.com>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Reviewed-by: NQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9d47bd21
    • J
      selftests: bpf: fix inlines in test_lwt_seg6local · 88f751b0
      Jiri Benc 提交于
      [ Upstream commit 11aca65ec4db09527d3e9b6b41a0615b7da4386b ]
      
      Selftests are reporting this failure in test_lwt_seg6local.sh:
      
      + ip netns exec ns2 ip -6 route add fb00::6 encap bpf in obj test_lwt_seg6local.o sec encap_srh dev veth2
      Error fetching program/map!
      Failed to parse eBPF program: Operation not permitted
      
      The problem is __attribute__((always_inline)) alone is not enough to prevent
      clang from inserting those functions in .text. In that case, .text is not
      marked as relocateable.
      
      See the output of objdump -h test_lwt_seg6local.o:
      
      Idx Name          Size      VMA               LMA               File off  Algn
        0 .text         00003530  0000000000000000  0000000000000000  00000040  2**3
                        CONTENTS, ALLOC, LOAD, READONLY, CODE
      
      This causes the iproute bpf loader to fail in bpf_fetch_prog_sec:
      bpf_has_call_data returns true but bpf_fetch_prog_relo fails as there's no
      relocateable .text section in the file.
      
      To fix this, convert to 'static __always_inline'.
      
      v2: Use 'static __always_inline' instead of 'static inline
          __attribute__((always_inline))'
      
      Fixes: c99a84ea ("selftests/bpf: test for seg6local End.BPF action")
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      88f751b0
    • L
      bpf, libbpf, smatch: Fix potential NULL pointer dereference · ef5b2043
      Leo Yan 提交于
      [ Upstream commit 33bae185f74d49a0d7b1bfaafb8e959efce0f243 ]
      
      Based on the following report from Smatch, fix the potential NULL
      pointer dereference check:
      
        tools/lib/bpf/libbpf.c:3493
        bpf_prog_load_xattr() warn: variable dereferenced before check 'attr'
        (see line 3483)
      
        3479 int bpf_prog_load_xattr(const struct bpf_prog_load_attr *attr,
        3480                         struct bpf_object **pobj, int *prog_fd)
        3481 {
        3482         struct bpf_object_open_attr open_attr = {
        3483                 .file           = attr->file,
        3484                 .prog_type      = attr->prog_type,
                                               ^^^^^^
        3485         };
      
      At the head of function, it directly access 'attr' without checking
      if it's NULL pointer. This patch moves the values assignment after
      validating 'attr' and 'attr->file'.
      Signed-off-by: NLeo Yan <leo.yan@linaro.org>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ef5b2043
    • A
      perf stat: Fix group lookup for metric group · e358d2ab
      Andi Kleen 提交于
      [ Upstream commit 2f87f33f4226523df9c9cc28f9874ea02fcc3d3f ]
      
      The metric group code tries to find a group it added earlier in the
      evlist. Fix the lookup to handle groups with partially overlaps
      correctly. When a sub string match fails and we reset the match, we have
      to compare the first element again.
      
      I also renamed the find_evsel function to find_evsel_group to make its
      purpose clearer.
      
      With the earlier changes this fixes:
      
      Before:
      
        % perf stat -M UPI,IPC sleep 1
        ...
               1,032,922      uops_retired.retire_slots #      1.1 UPI
               1,896,096      inst_retired.any
               1,896,096      inst_retired.any
               1,177,254      cpu_clk_unhalted.thread
      
      After:
      
        % perf stat -M UPI,IPC sleep 1
        ...
              1,013,193      uops_retired.retire_slots #      1.1 UPI
                 932,033      inst_retired.any
                 932,033      inst_retired.any          #      0.9 IPC
               1,091,245      cpu_clk_unhalted.thread
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Fixes: b18f3e36 ("perf stat: Support JSON metrics in perf stat")
      Link: http://lkml.kernel.org/r/20190624193711.35241-4-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e358d2ab
    • A
      perf stat: Make metric event lookup more robust · a64e018b
      Andi Kleen 提交于
      [ Upstream commit 145c407c808352acd625be793396fd4f33c794f8 ]
      
      After setting up metric groups through the event parser, the metricgroup
      code looks them up again in the event list.
      
      Make sure we only look up events that haven't been used by some other
      metric. The data structures currently cannot handle more than one metric
      per event. This avoids problems with multiple events partially
      overlapping.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Link: http://lkml.kernel.org/r/20190624193711.35241-2-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a64e018b
    • B
      bpf: fix uapi bpf_prog_info fields alignment · 7343178c
      Baruch Siach 提交于
      [ Upstream commit 0472301a28f6cf53a6bc5783e48a2d0bbff4682f ]
      
      Merge commit 1c8c5a9d ("Merge
      git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next") undid the
      fix from commit 36f9814a ("bpf: fix uapi hole for 32 bit compat
      applications") by taking the gpl_compatible 1-bit field definition from
      commit b85fab0e ("bpf: Add gpl_compatible flag to struct
      bpf_prog_info") as is. That breaks architectures with 16-bit alignment
      like m68k. Add 31-bit pad after gpl_compatible to restore alignment of
      following fields.
      
      Thanks to Dmitry V. Levin his analysis of this bug history.
      Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
      Acked-by: NSong Liu <songliubraving@fb.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7343178c
    • K
      perf tools: Increase MAX_NR_CPUS and MAX_CACHES · 1182ff22
      Kyle Meyer 提交于
      [ Upstream commit 9f94c7f947e919c343b30f080285af53d0fa9902 ]
      
      Attempting to profile 1024 or more CPUs with perf causes two errors:
      
        perf record -a
        [ perf record: Woken up X times to write data ]
        way too many cpu caches..
        [ perf record: Captured and wrote X MB perf.data (X samples) ]
      
        perf report -C 1024
        Error: failed to set  cpu bitmap
        Requested CPU 1024 too large. Consider raising MAX_NR_CPUS
      
        Increasing MAX_NR_CPUS from 1024 to 2048 and redefining MAX_CACHES as
        MAX_NR_CPUS * 4 returns normal functionality to perf:
      
        perf record -a
        [ perf record: Woken up X times to write data ]
        [ perf record: Captured and wrote X MB perf.data (X samples) ]
      
        perf report -C 1024
        ...
      Signed-off-by: NKyle Meyer <kyle.meyer@hpe.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20190620193630.154025-1-meyerk@stormcage.eag.rdlabs.hpecorp.netSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1182ff22
    • A
      perf evsel: Make perf_evsel__name() accept a NULL argument · 4c57957e
      Arnaldo Carvalho de Melo 提交于
      [ Upstream commit fdbdd7e8580eac9bdafa532746c865644d125e34 ]
      
      In which case it simply returns "unknown", like when it can't figure out
      the evsel->name value.
      
      This makes this code more robust and fixes a problem in 'perf trace'
      where a NULL evsel was being passed to a routine that only used the
      evsel for printing its name when a invalid syscall id was passed.
      Reported-by: NLeo Yan <leo.yan@linaro.org>
      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-f30ztaasku3z935cn3ak3h53@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4c57957e
    • T
      perf report: Fix OOM error in TUI mode on s390 · eac8b39d
      Thomas Richter 提交于
      [ Upstream commit 8a07aa4e9b7b0222129c07afff81634a884b2866 ]
      
      Debugging a OOM error using the TUI interface revealed this issue
      on s390:
      
      [tmricht@m83lp54 perf]$ cat /proc/kallsyms |sort
      ....
      00000001119b7158 B radix_tree_node_cachep
      00000001119b8000 B __bss_stop
      00000001119b8000 B _end
      000003ff80002850 t autofs_mount	[autofs4]
      000003ff80002868 t autofs_show_options	[autofs4]
      000003ff80002a98 t autofs_evict_inode	[autofs4]
      ....
      
      There is a huge gap between the last kernel symbol
      __bss_stop/_end and the first kernel module symbol
      autofs_mount (from autofs4 module).
      
      After reading the kernel symbol table via functions:
      
       dso__load()
       +--> dso__load_kernel_sym()
            +--> dso__load_kallsyms()
      	   +--> __dso_load_kallsyms()
      	        +--> symbols__fixup_end()
      
      the symbol __bss_stop has a start address of 1119b8000 and
      an end address of 3ff80002850, as can be seen by this debug statement:
      
        symbols__fixup_end __bss_stop start:0x1119b8000 end:0x3ff80002850
      
      The size of symbol __bss_stop is 0x3fe6e64a850 bytes!
      It is the last kernel symbol and fills up the space until
      the first kernel module symbol.
      
      This size kills the TUI interface when executing the following
      code:
      
        process_sample_event()
          hist_entry_iter__add()
            hist_iter__report_callback()
              hist_entry__inc_addr_samples()
                symbol__inc_addr_samples(symbol = __bss_stop)
                  symbol__cycles_hist()
                     annotated_source__alloc_histograms(...,
      				                symbol__size(sym),
      		                                ...)
      
      This function allocates memory to save sample histograms.
      The symbol_size() marco is defined as sym->end - sym->start, which
      results in above value of 0x3fe6e64a850 bytes and
      the call to calloc() in annotated_source__alloc_histograms() fails.
      
      The histgram memory allocation might fail, make this failure
      no-fatal and continue processing.
      
      Output before:
      [tmricht@m83lp54 perf]$ ./perf --debug stderr=1 report -vvvvv \
      					      -i ~/slow.data 2>/tmp/2
      [tmricht@m83lp54 perf]$ tail -5 /tmp/2
        __symbol__inc_addr_samples(875): ENOMEM! sym->name=__bss_stop,
      		start=0x1119b8000, addr=0x2aa0005eb08, end=0x3ff80002850,
      		func: 0
      problem adding hist entry, skipping event
      0x938b8 [0x8]: failed to process type: 68 [Cannot allocate memory]
      [tmricht@m83lp54 perf]$
      
      Output after:
      [tmricht@m83lp54 perf]$ ./perf --debug stderr=1 report -vvvvv \
      					      -i ~/slow.data 2>/tmp/2
      [tmricht@m83lp54 perf]$ tail -5 /tmp/2
         symbol__inc_addr_samples map:0x1597830 start:0x110730000 end:0x3ff80002850
         symbol__hists notes->src:0x2aa2a70 nr_hists:1
         symbol__inc_addr_samples sym:unlink_anon_vmas src:0x2aa2a70
         __symbol__inc_addr_samples: addr=0x11094c69e
         0x11094c670 unlink_anon_vmas: period++ [addr: 0x11094c69e, 0x2e, evidx=0]
         	=> nr_samples: 1, period: 526008
      [tmricht@m83lp54 perf]$
      
      There is no error about failed memory allocation and the TUI interface
      shows all entries.
      Signed-off-by: NThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: NHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/90cb5607-3e12-5167-682d-978eba7dafa8@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      eac8b39d
    • T
      perf test 6: Fix missing kvm module load for s390 · be32a9dc
      Thomas Richter 提交于
      [ Upstream commit 53fe307dfd309e425b171f6272d64296a54f4dff ]
      
      Command
      
         # perf test -Fv 6
      
      fails with error
      
         running test 100 'kvm-s390:kvm_s390_create_vm' failed to parse
          event 'kvm-s390:kvm_s390_create_vm', err -1, str 'unknown tracepoint'
          event syntax error: 'kvm-s390:kvm_s390_create_vm'
                               \___ unknown tracepoint
      
      when the kvm module is not loaded or not built in.
      
      Fix this by adding a valid function which tests if the module
      is loaded. Loaded modules (or builtin KVM support) have a
      directory named
        /sys/kernel/debug/tracing/events/kvm-s390
      for this tracepoint.
      
      Check for existence of this directory.
      Signed-off-by: NThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/20190604053504.43073-1-tmricht@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      be32a9dc
    • M
      perf cs-etm: Properly set the value of 'old' and 'head' in snapshot mode · 3662d8bc
      Mathieu Poirier 提交于
      [ Upstream commit e45c48a9a4d20ebc7b639a62c3ef8f4b08007027 ]
      
      This patch adds the necessary intelligence to properly compute the value
      of 'old' and 'head' when operating in snapshot mode.  That way we can
      get the latest information in the AUX buffer and be compatible with the
      generic AUX ring buffer mechanic.
      
      Tester notes:
      
      > Leo, have you had the chance to test/review this one? Suzuki?
      
      Sure.  I applied this patch on the perf/core branch (with latest
      commit 3e4fbf36c1e3 'perf augmented_raw_syscalls: Move reading
      filename to the loop') and passed testing with below steps:
      
        # perf record -e cs_etm/@tmc_etr0/ -S -m,64 --per-thread ./sort &
        [1] 19097
        Bubble sorting array of 30000 elements
      
        # kill -USR2 19097
        # kill -USR2 19097
        # kill -USR2 19097
        [ perf record: Woken up 4 times to write data ]
        [ perf record: Captured and wrote 0.753 MB perf.data ]
      Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
      Tested-by: NLeo Yan <leo.yan@linaro.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Link: http://lkml.kernel.org/r/20190605161633.12245-1-mathieu.poirier@linaro.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3662d8bc
    • J
      perf jvmti: Address gcc string overflow warning for strncpy() · 713737ca
      Jiri Olsa 提交于
      [ Upstream commit 279ab04dbea1370d2eac0f854270369ccaef8a44 ]
      
      We are getting false positive gcc warning when we compile with gcc9 (9.1.1):
      
           CC       jvmti/libjvmti.o
         In file included from /usr/include/string.h:494,
                          from jvmti/libjvmti.c:5:
         In function ‘strncpy’,
             inlined from ‘copy_class_filename.constprop’ at jvmti/libjvmti.c:166:3:
         /usr/include/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
           106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
               |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         jvmti/libjvmti.c: In function ‘copy_class_filename.constprop’:
         jvmti/libjvmti.c:165:26: note: length computed here
           165 |   size_t file_name_len = strlen(file_name);
               |                          ^~~~~~~~~~~~~~~~~
         cc1: all warnings being treated as errors
      
      As per Arnaldo's suggestion use strlcpy(), which does the same thing and keeps
      gcc silent.
      Suggested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ben Gainey <ben.gainey@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/20190531131321.GB1281@kravaSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      713737ca
    • A
      cpupower : frequency-set -r option misses the last cpu in related cpu list · c360eb59
      Abhishek Goel 提交于
      [ Upstream commit 04507c0a9385cc8280f794a36bfff567c8cc1042 ]
      
      To set frequency on specific cpus using cpupower, following syntax can
      be used :
      cpupower -c #i frequency-set -f #f -r
      
      While setting frequency using cpupower frequency-set command, if we use
      '-r' option, it is expected to set frequency for all cpus related to
      cpu #i. But it is observed to be missing the last cpu in related cpu
      list. This patch fixes the problem.
      Signed-off-by: NAbhishek Goel <huntbag@linux.vnet.ibm.com>
      Reviewed-by: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c360eb59
    • A
      perf annotate TUI browser: Do not use member from variable within its own initialization · a6dd4862
      Arnaldo Carvalho de Melo 提交于
      [ Upstream commit da2019633f0b5c105ce658aada333422d8cb28fe ]
      
      Some compilers will complain when using a member of a struct to
      initialize another member, in the same struct initialization.
      
      For instance:
      
        debian:8      Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
        oraclelinux:7 clang version 3.4.2 (tags/RELEASE_34/dot2-final)
      
      Produce:
      
        ui/browsers/annotate.c:104:12: error: variable 'ops' is uninitialized when used within its own initialization [-Werror,-Wuninitialized]
                                                    (!ops.current_entry ||
                                                      ^~~
        1 error generated.
      
      So use an extra variable, initialized just before that struct, to have
      the value used in the expressions used to init two of the struct
      members.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Fixes: c298304b ("perf annotate: Use a ops table for annotation_line__write()")
      Link: https://lkml.kernel.org/n/tip-f9nexro58q62l3o9hez8hr0i@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a6dd4862
  4. 14 7月, 2019 1 次提交
    • J
      perf pmu: Fix uncore PMU alias list for ARM64 · d8e26651
      John Garry 提交于
      commit 599ee18f0740d7661b8711249096db94c09bc508 upstream.
      
      In commit 292c34c1 ("perf pmu: Fix core PMU alias list for X86
      platform"), we fixed the issue of CPU events being aliased to uncore
      events.
      
      Fix this same issue for ARM64, since the said commit left the (broken)
      behaviour untouched for ARM64.
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Shaokun Zhang <zhangshaokun@hisilicon.com>
      Cc: Thomas Richter <tmricht@linux.ibm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linuxarm@huawei.com
      Cc: stable@vger.kernel.org
      Fixes: 292c34c1 ("perf pmu: Fix core PMU alias list for X86 platform")
      Link: http://lkml.kernel.org/r/1560521283-73314-2-git-send-email-john.garry@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d8e26651
  5. 10 7月, 2019 1 次提交
  6. 03 7月, 2019 4 次提交
    • J
      bpf: lpm_trie: check left child of last leftmost node for NULL · 4992d4af
      Jonathan Lemon 提交于
      commit da2577fdd0932ea4eefe73903f1130ee366767d2 upstream.
      
      If the leftmost parent node of the tree has does not have a child
      on the left side, then trie_get_next_key (and bpftool map dump) will
      not look at the child on the right.  This leads to the traversal
      missing elements.
      
      Lookup is not affected.
      
      Update selftest to handle this case.
      
      Reproducer:
      
       bpftool map create /sys/fs/bpf/lpm type lpm_trie key 6 \
           value 1 entries 256 name test_lpm flags 1
       bpftool map update pinned /sys/fs/bpf/lpm key  8 0 0 0  0   0 value 1
       bpftool map update pinned /sys/fs/bpf/lpm key 16 0 0 0  0 128 value 2
       bpftool map dump   pinned /sys/fs/bpf/lpm
      
      Returns only 1 element. (2 expected)
      
      Fixes: b471f2f1 ("bpf: implement MAP_GET_NEXT_KEY command for LPM_TRIE")
      Signed-off-by: NJonathan Lemon <jonathan.lemon@gmail.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4992d4af
    • A
      perf header: Fix unchecked usage of strncpy() · 6461a454
      Arnaldo Carvalho de Melo 提交于
      commit 5192bde7d98c99f2cd80225649e3c2e7493722f7 upstream.
      
      The strncpy() function may leave the destination string buffer
      unterminated, better use strlcpy() that we have a __weak fallback
      implementation for systems without it.
      
      This fixes this warning on an Alpine Linux Edge system with gcc 8.2:
      
        util/header.c: In function 'perf_event__synthesize_event_update_name':
        util/header.c:3625:2: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
          strncpy(ev->data, evsel->name, len);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        util/header.c:3618:15: note: length computed here
          size_t len = strlen(evsel->name);
                       ^~~~~~~~~~~~~~~~~~~
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Fixes: a6e52817 ("perf tools: Add event_update event unit type")
      Link: https://lkml.kernel.org/n/tip-wycz66iy8dl2z3yifgqf894p@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6461a454
    • A
      perf help: Remove needless use of strncpy() · 0bf5d53b
      Arnaldo Carvalho de Melo 提交于
      commit b6313899f4ed2e76b8375cf8069556f5b94fbff0 upstream.
      
      Since we make sure the destination buffer has at least strlen(orig) + 1,
      no need to do a strncpy(dest, orig, strlen(orig)), just use strcpy(dest,
      orig).
      
      This silences this gcc 8.2 warning on Alpine Linux:
      
        In function 'add_man_viewer',
            inlined from 'perf_help_config' at builtin-help.c:284:3:
        builtin-help.c:192:2: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
          strncpy((*p)->name, name, len);
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        builtin-help.c: In function 'perf_help_config':
        builtin-help.c:187:15: note: length computed here
          size_t len = strlen(name);
                       ^~~~~~~~~~~~
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Fixes: 07800601 ("perf_counter tools: add in basic glue from Git")
      Link: https://lkml.kernel.org/n/tip-2f69l7drca427ob4km8i7kvo@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0bf5d53b
    • A
      perf ui helpline: Use strlcpy() as a shorter form of strncpy() + explicit set nul · 6e75d927
      Arnaldo Carvalho de Melo 提交于
      commit 4d0f16d059ddb91424480d88473f7392f24aebdc upstream.
      
      The strncpy() function may leave the destination string buffer
      unterminated, better use strlcpy() that we have a __weak fallback
      implementation for systems without it.
      
      In this case we are actually setting the null byte at the right place,
      but since we pass the buffer size as the limit to strncpy() and not
      it minus one, gcc ends up warning us about that, see below. So, lets
      just switch to the shorter form provided by strlcpy().
      
      This fixes this warning on an Alpine Linux Edge system with gcc 8.2:
      
        ui/tui/helpline.c: In function 'tui_helpline__push':
        ui/tui/helpline.c:27:2: error: 'strncpy' specified bound 512 equals destination size [-Werror=stringop-truncation]
          strncpy(ui_helpline__current, msg, sz)[sz - 1] = '\0';
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        cc1: all warnings being treated as errors
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Fixes: e6e90468 ("perf ui: Introduce struct ui_helpline")
      Link: https://lkml.kernel.org/n/tip-d1wz0hjjsh19xbalw69qpytj@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e75d927
  7. 25 6月, 2019 5 次提交
    • N
      selftests: vm: install test_vmalloc.sh for run_vmtests · bf51ec92
      Naresh Kamboju 提交于
      [ Upstream commit bc2cce3f2ebcae02aa4bb29e3436bf75ee674c32 ]
      
      Add test_vmalloc.sh to TEST_FILES to make sure it gets installed for
      run_vmtests.
      
      Fixed below error:
      ./run_vmtests: line 217: ./test_vmalloc.sh: No such file or directory
      
      Tested with: make TARGETS=vm install INSTALL_PATH=$PWD/x
      Signed-off-by: NNaresh Kamboju <naresh.kamboju@linaro.org>
      Signed-off-by: NShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bf51ec92
    • A
      kselftest/cgroup: fix incorrect test_core skip · a0e8215e
      Alex Shi 提交于
      [ Upstream commit f97f3f8839eb9de5843066d80819884f7722c8c5 ]
      
      The test_core will skip the
      test_cgcore_no_internal_process_constraint_on_threads test case if the
      'cpu' controller missing in root's subtree_control. In fact we need to
      set the 'cpu' in subtree_control, to make the testing meaningful.
      
      ./test_core
      ...
      ok 4 # skip test_cgcore_no_internal_process_constraint_on_threads
      ...
      Signed-off-by: NAlex Shi <alex.shi@linux.alibaba.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Claudio Zumbo <claudioz@fb.com>
      Cc: Claudio <claudiozumbo@gmail.com>
      Cc: linux-kselftest@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Reviewed-by: NRoman Gushchin <guro@fb.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a0e8215e
    • A
      kselftest/cgroup: fix unexpected testing failure on test_core · 59243d6f
      Alex Shi 提交于
      [ Upstream commit 00e38a5d753d7788852f81703db804a60a84c26e ]
      
      The cgroup testing relys on the root cgroup's subtree_control setting,
      If the 'memory' controller isn't set, some test cases will be failed
      as following:
      
      $sudo  ./test_core
      not ok 1 test_cgcore_internal_process_constraint
      ok 2 test_cgcore_top_down_constraint_enable
      not ok 3 test_cgcore_top_down_constraint_disable
      ...
      
      To correct this unexpected failure, this patch write the 'memory' to
      subtree_control of root to get a right result.
      Signed-off-by: NAlex Shi <alex.shi@linux.alibaba.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Claudio Zumbo <claudioz@fb.com>
      Cc: Claudio <claudiozumbo@gmail.com>
      Cc: linux-kselftest@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Reviewed-by: NRoman Gushchin <guro@fb.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      59243d6f
    • A
      kselftest/cgroup: fix unexpected testing failure on test_memcontrol · 9c2eebe3
      Alex Shi 提交于
      [ Upstream commit f6131f28057d4fd8922599339e701a2504e0f23d ]
      
      The cgroup testing relies on the root cgroup's subtree_control setting,
      If the 'memory' controller isn't set, all test cases will be failed
      as following:
      
      $ sudo ./test_memcontrol
      not ok 1 test_memcg_subtree_control
      not ok 2 test_memcg_current
      ok 3 # skip test_memcg_min
      not ok 4 test_memcg_low
      not ok 5 test_memcg_high
      not ok 6 test_memcg_max
      not ok 7 test_memcg_oom_events
      ok 8 # skip test_memcg_swap_max
      not ok 9 test_memcg_sock
      not ok 10 test_memcg_oom_group_leaf_events
      not ok 11 test_memcg_oom_group_parent_events
      not ok 12 test_memcg_oom_group_score_events
      
      To correct this unexpected failure, this patch write the 'memory' to
      subtree_control of root to get a right result.
      Signed-off-by: NAlex Shi <alex.shi@linux.alibaba.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Jay Kamat <jgkamat@fb.com>
      Cc: linux-kselftest@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Reviewed-by: NRoman Gushchin <guro@fb.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NShuah Khan <skhan@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9c2eebe3
    • A
      objtool: Support per-function rodata sections · 6a997c3a
      Allan Xavier 提交于
      commit 4a60aa05a0634241ce17f957bf9fb5ac1eed6576 upstream.
      
      Add support for processing switch jump tables in objects with multiple
      .rodata sections, such as those created by '-ffunction-sections' and
      '-fdata-sections'.  Currently, objtool always looks in .rodata for jump
      table information, which results in many "sibling call from callable
      instruction with modified stack frame" warnings with objects compiled
      using those flags.
      
      The fix is comprised of three parts:
      
      1. Flagging all .rodata sections when importing ELF information for
         easier checking later.
      
      2. Keeping a reference to the section each relocation is from in order
         to get the list_head for the other relocations in that section.
      
      3. Finding jump tables by following relocations to .rodata sections,
         rather than always referencing a single global .rodata section.
      
      The patch has been tested without data sections enabled and no
      differences in the resulting orc unwind information were seen.
      
      Note that as objtool adds terminators to end of each .text section the
      unwind information generated between a function+data sections build and
      a normal build aren't directly comparable. Manual inspection suggests
      that objtool is now generating the correct information, or at least
      making more of an effort to do so than it did previously.
      Signed-off-by: NAllan Xavier <allan.x.xavier@oracle.com>
      Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/099bdc375195c490dda04db777ee0b95d566ded1.1536325914.git.jpoimboe@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a997c3a
  8. 22 6月, 2019 4 次提交
    • T
      perf record: Fix s390 missing module symbol and warning for non-root users · 60a3e3b9
      Thomas Richter 提交于
      [ Upstream commit 6738028dd57df064b969d8392c943ef3b3ae705d ]
      
      Command 'perf record' and 'perf report' on a system without kernel
      debuginfo packages uses /proc/kallsyms and /proc/modules to find
      addresses for kernel and module symbols. On x86 this works for root and
      non-root users.
      
      On s390, when invoked as non-root user, many of the following warnings
      are shown and module symbols are missing:
      
          proc/{kallsyms,modules} inconsistency while looking for
              "[sha1_s390]" module!
      
      Command 'perf record' creates a list of module start addresses by
      parsing the output of /proc/modules and creates a PERF_RECORD_MMAP
      record for the kernel and each module. The following function call
      sequence is executed:
      
        machine__create_kernel_maps
          machine__create_module
            modules__parse
              machine__create_module --> for each line in /proc/modules
                arch__fix_module_text_start
      
      Function arch__fix_module_text_start() is s390 specific. It opens
      file /sys/module/<name>/sections/.text to extract the module's .text
      section start address. On s390 the module loader prepends a header
      before the first section, whereas on x86 the module's text section
      address is identical the the module's load address.
      
      However module section files are root readable only. For non-root the
      read operation fails and machine__create_module() returns an error.
      Command perf record does not generate any PERF_RECORD_MMAP record
      for loaded modules. Later command perf report complains about missing
      module maps.
      
      To fix this function arch__fix_module_text_start() always returns
      success. For root users there is no change, for non-root users
      the module's load address is used as module's text start address
      (the prepended header then counts as part of the text section).
      
      This enable non-root users to use module symbols and avoid the
      warning when perf report is executed.
      
      Output before:
      
        [tmricht@m83lp54 perf]$ ./perf report -D | fgrep MMAP
        0 0x168 [0x50]: PERF_RECORD_MMAP ... x [kernel.kallsyms]_text
      
      Output after:
      
        [tmricht@m83lp54 perf]$ ./perf report -D | fgrep MMAP
        0 0x168 [0x50]: PERF_RECORD_MMAP ... x [kernel.kallsyms]_text
        0 0x1b8 [0x98]: PERF_RECORD_MMAP ... x /lib/modules/.../autofs4.ko.xz
        0 0x250 [0xa8]: PERF_RECORD_MMAP ... x /lib/modules/.../sha_common.ko.xz
        0 0x2f8 [0x98]: PERF_RECORD_MMAP ... x /lib/modules/.../des_generic.ko.xz
      Signed-off-by: NThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: NHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Link: http://lkml.kernel.org/r/20190522144601.50763-4-tmricht@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      60a3e3b9
    • N
      perf namespace: Protect reading thread's namespace · be0e6266
      Namhyung Kim 提交于
      [ Upstream commit 6584140ba9e6762dd7ec73795243289b914f31f9 ]
      
      It seems that the current code lacks holding the namespace lock in
      thread__namespaces().  Otherwise it can see inconsistent results.
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Krister Johansen <kjlx@templeofstupid.com>
      Link: http://lkml.kernel.org/r/20190522053250.207156-2-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      be0e6266
    • S
      perf data: Fix 'strncat may truncate' build failure with recent gcc · 7d523e33
      Shawn Landden 提交于
      [ Upstream commit 97acec7df172cd1e450f81f5e293c0aa145a2797 ]
      
      This strncat() is safe because the buffer was allocated with zalloc(),
      however gcc doesn't know that. Since the string always has 4 non-null
      bytes, just use memcpy() here.
      
          CC       /home/shawn/linux/tools/perf/util/data-convert-bt.o
        In file included from /usr/include/string.h:494,
                         from /home/shawn/linux/tools/lib/traceevent/event-parse.h:27,
                         from util/data-convert-bt.c:22:
        In function ‘strncat’,
            inlined from ‘string_set_value’ at util/data-convert-bt.c:274:4:
        /usr/include/powerpc64le-linux-gnu/bits/string_fortified.h:136:10: error: ‘__builtin_strncat’ output may be truncated copying 4 bytes from a string of length 4 [-Werror=stringop-truncation]
          136 |   return __builtin___strncat_chk (__dest, __src, __len, __bos (__dest));
              |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Signed-off-by: NShawn Landden <shawn@git.icu>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      LPU-Reference: 20190518183238.10954-1-shawn@git.icu
      Link: https://lkml.kernel.org/n/tip-289f1jice17ta7tr3tstm9jm@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      7d523e33
    • J
      selftests: netfilter: missing error check when setting up veth interface · ef4ffa0f
      Jeffrin Jose T 提交于
      [ Upstream commit 82ce6eb1dd13fd12e449b2ee2c2ec051e6f52c43 ]
      
      A test for the basic NAT functionality uses ip command which needs veth
      device. There is a condition where the kernel support for veth is not
      compiled into the kernel and the test script breaks. This patch contains
      code for reasonable error display and correct code exit.
      Signed-off-by: NJeffrin Jose T <jeffrin@rajagiritech.edu.in>
      Acked-by: NFlorian Westphal <fw@strlen.de>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ef4ffa0f
  9. 19 6月, 2019 1 次提交
    • S
      tools/kvm_stat: fix fields filter for child events · 2399b2ac
      Stefan Raspl 提交于
      [ Upstream commit 883d25e70b2f699fed9017e509d1ef8e36229b89 ]
      
      The fields filter would not work with child fields, as the respective
      parents would not be included. No parents displayed == no childs displayed.
      To reproduce, run on s390 (would work on other platforms, too, but would
      require a different filter name):
      - Run 'kvm_stat -d'
      - Press 'f'
      - Enter 'instruct'
      Notice that events like instruction_diag_44 or instruction_diag_500 are not
      displayed - the output remains empty.
      With this patch, we will filter by matching events and their parents.
      However, consider the following example where we filter by
      instruction_diag_44:
      
        kvm statistics - summary
                         regex filter: instruction_diag_44
         Event                                         Total %Total CurAvg/s
         exit_instruction                                276  100.0       12
           instruction_diag_44                           256   92.8       11
         Total                                           276              12
      
      Note that the parent ('exit_instruction') displays the total events, but
      the childs listed do not match its total (256 instead of 276). This is
      intended (since we're filtering all but one child), but might be confusing
      on first sight.
      Signed-off-by: NStefan Raspl <raspl@linux.ibm.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      2399b2ac