linux-stable.git/tools/perf/util/header.c, branch linux-4.4.y

perf header: Fix use of unitialized value warning

2019-08-25T08:52:59+00:00

[ Upstream commit 20f9781f491360e7459c589705a2e4b1f136bee9 ]

When building our local version of perf with MSAN (Memory Sanitizer) and
running the perf record command, MSAN throws a use of uninitialized
value warning in "tools/perf/util/util.c:333:6".

This warning stems from the "buf" variable being passed into "write".
It originated as the variable "ev" with the type union perf_event*
defined in the "perf_event__synthesize_attr" function in
"tools/perf/util/header.c".

In the "perf_event__synthesize_attr" function they allocate space with a malloc
call using ev, then go on to only assign some of the member variables before
passing "ev" on as a parameter to the "process" function therefore "ev"
contains uninitialized memory. Changing the malloc call to zalloc to initialize
all the members of "ev" which gets rid of the warning.

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: Numfor Mbiziwo-Tiapo 
Cc: Alexander Shishkin 
Cc: Ian Rogers 
Cc: Jiri Olsa 
Cc: Mark Drayton 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Song Liu 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/r/20190724234500.253358-2-nums@google.com
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin

perf header: Fix divide by zero error if f_header.attr_size==0

2019-08-25T08:52:59+00:00

[ Upstream commit 7622236ceb167aa3857395f9bdaf871442aa467e ]

So I have been having lots of trouble with hand-crafted perf.data files
causing segfaults and the like, so I have started fuzzing the perf tool.

First issue found:

If f_header.attr_size is 0 in the perf.data file, then perf will crash
with a divide-by-zero error.

Committer note:

Added a pr_err() to tell the user why the command failed.

Signed-off-by: Vince Weaver 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1907231100440.14532@macbook-air
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin

perf header: Set proper module name when build-id event found

2018-04-13T17:50:18+00:00

[ Upstream commit 1deec1bd96ccd8beb04d2112a6d12fe20505c3a6 ]

When perf processes build-id event, it creates DSOs with the build-id.
But it didn't set the module short name (like '[module-name]') so when
processing a kernel mmap event of the module, it cannot found the DSO as
it only checks the short names.

That leads for perf to create a same DSO without the build-id info and
it'll lookup the system path even if the DSO is already in the build-id
cache.  After kernel was updated, perf cannot find the DSO  and cannot
show symbols in it anymore.

You can see this if you have an old data file (w/ old kernel version):

  $ perf report -i perf.data.old -v |& grep scsi_mod
  build id event received for /lib/modules/3.19.2-1-ARCH/kernel/drivers/scsi/scsi_mod.ko.gz : cafe1ce6ca13a98a5d9ed3425cde249e57a27fc1
  Failed to open /lib/modules/3.19.2-1-ARCH/kernel/drivers/scsi/scsi_mod.ko.gz, continuing without symbols
  ...

The second message didn't show the build-id.  With this patch:

  $ perf report -i perf.data.old -v |& grep scsi_mod
  build id event received for /lib/modules/3.19.2-1-ARCH/kernel/drivers/scsi/scsi_mod.ko.gz: cafe1ce6ca13a98a5d9ed3425cde249e57a27fc1
  /lib/modules/3.19.2-1-ARCH/kernel/drivers/scsi/scsi_mod.ko.gz with build id cafe1ce6ca13a98a5d9ed3425cde249e57a27fc1 not found, continuing without symbols
  ...

Now it shows the build-id but still cannot load the symbol table.  This
is a different problem which will be fixed in the next patch.

Signed-off-by: Namhyung Kim 
Acked-by: Jiri Olsa 
Cc: Andi Kleen 
Cc: David Ahern 
Cc: Peter Zijlstra 
Cc: kernel-team@lge.com
Link: http://lkml.kernel.org/r/20170531120105.21731-1-namhyung@kernel.org
[ Fix the build on older compilers (debian <= 8, fedora <= 21, etc) wrt kmod_path var init ]
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'perf/urgent' into perf/core, to resolve a conflict

2015-09-16T07:19:56+00:00

Conflicts:
	tools/perf/ui/browsers/hists.c

Signed-off-by: Ingo Molnar

perf machine: Add pointer to sample's environment

2015-09-14T15:50:29+00:00

The 'struct machine' represents the machine where the samples were/are
being collected, and we also have a 'struct perf_env' with extra details
about such machine, that we were collecting at 'perf.data' creation time
but we also needed when no perf.data file is being used, such as in
'perf top'.

So, get those structs closer together, as they provide a bigger picture
of the sample's environment.

In 'perf session', when the file argument is NULL, we can assume that
the tool is sampling the running machine, so point machine->env to
the global put in place in previous patches, while set it to the
perf_header.env one when reading from a file.

This paves the way for machine->env to be used in
perf_event__preprocess_sample to populate addr_location.socket.

Tested-by: Wang Nan 
Cc: Adrian Hunter 
Cc: Borislav Petkov 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Namhyung Kim 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-2ajotl0khscutm68exictoy9@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf env: Introduce read_cpu_topology_map() method

2015-09-14T15:50:28+00:00

Out of the code to write the cpu topology map in the perf.data file
header.

Now if one needs the CPU topology map for the running machine, one needs
to call perf_env__read_cpu_topology_map(perf_env) and the info will be
stored in perf_env.cpu.

For now we're using a global perf_env variable, that will have its
contents freed after we run a builtin.

v2: Check perf_env__read_cpu_topology_map() return in
    write_cpu_topology() (Kan Liang)

Cc: Adrian Hunter 
Cc: Borislav Petkov 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Namhyung Kim 
Cc: Stephane Eranian 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/1441828225-667-5-git-send-email-acme@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf env: Read msr pmu type from header

2015-09-14T15:50:24+00:00

Get msr pmu type when processing pmu_mappings

Signed-off-by: Kan Liang 
Acked-by: Jiri Olsa 
Link: http://lkml.kernel.org/n/tip-3ngei63gepydwxhvytl2wx89@git.kernel.org
[ Fixed it up wrt moving perf_env from header.h ]
Signed-off-by: Arnaldo Carvalho de Melo

perf env: Adopt perf_header__set_cmdline

2015-09-14T15:50:21+00:00

Move this from two globals to perf_env global, that eventually will
be just perf_header->env or something else, to ease the refactoring
series, leave it as a global and go on reading more of its fields,
not as part of the header writing process but as a perf_env init one
that will be used for perf.data-less situations.

Tested-by: Wang Nan 
Cc: Adrian Hunter 
Cc: Borislav Petkov 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Namhyung Kim 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-2j78tdf8zn1ci0y6ji15bifj@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf header: Fixup reading of HEADER_NRCPUS feature

2015-09-13T14:41:34+00:00

The original patch introducing this header wrote the number of CPUs available
and online in one order and then swapped those values when reading, fix it.

Before:

  # perf record usleep 1
  # perf report --header-only | grep 'nrcpus \(online\|avail\)'
  # nrcpus online : 4
  # nrcpus avail : 4
  # echo 0 > /sys/devices/system/cpu/cpu2/online
  # perf record usleep 1
  # perf report --header-only | grep 'nrcpus \(online\|avail\)'
  # nrcpus online : 4
  # nrcpus avail : 3
  # echo 0 > /sys/devices/system/cpu/cpu1/online
  # perf record usleep 1
  # perf report --header-only | grep 'nrcpus \(online\|avail\)'
  # nrcpus online : 4
  # nrcpus avail : 2

After the fix, bringing back the CPUs online:

  # perf report --header-only | grep 'nrcpus \(online\|avail\)'
  # nrcpus online : 2
  # nrcpus avail : 4
  # echo 1 > /sys/devices/system/cpu/cpu2/online
  # perf record usleep 1
  # perf report --header-only | grep 'nrcpus \(online\|avail\)'
  # nrcpus online : 3
  # nrcpus avail : 4
  # echo 1 > /sys/devices/system/cpu/cpu1/online
  # perf record usleep 1
  # perf report --header-only | grep 'nrcpus \(online\|avail\)'
  # nrcpus online : 4
  # nrcpus avail : 4

Acked-by: Namhyung Kim 
Cc: Adrian Hunter 
Cc: Borislav Petkov 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Kan Liang 
Cc: Stephane Eranian 
Cc: Wang Nan 
Fixes: fbe96f29ce4b ("perf tools: Make perf.data more self-descriptive (v8)")
Link: http://lkml.kernel.org/r/20150911153323.GP23511@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Store the cpu socket and core ids in the perf.data header

2015-09-02T19:30:47+00:00

This patch stores the cpu socket_id and core_id in a perf.data header,
and reads them into the perf_env struct when processing perf.data files.

The changes modifies the CPU_TOPOLOGY section, making sure it is
backward/forward compatible.

The patch checks the section size before reading the core and socket ids.

It never reads data crossing the section boundary.  An old perf binary
without this patch can also correctly read the perf.data from a new perf
with this patch.

Because the new info is added at the end of the cpu_topology section, an
old perf tool ignores the extra data.

Examples:

1. New perf with this patch read perf.data from an old perf without the
   patch:

  $ perf_new report -i perf_old.data --header-only -I
  ......
  # sibling threads : 33
  # sibling threads : 34
  # sibling threads : 35
  # Core ID and Socket ID information is not available
  # node0 meminfo  : total = 32823872 kB, free = 29315548 kB
  # node0 cpu list : 0-17,36-53
  ......

2. Old perf without the patch reads perf.data from a new perf with the
   patch:

  $ perf_old report -i perf_new.data --header-only -I
  ......
  # sibling threads : 33
  # sibling threads : 34
  # sibling threads : 35
  # node0 meminfo  : total = 32823872 kB, free = 29190932 kB
  # node0 cpu list : 0-17,36-53
  ......

3. New perf read new perf.data:

  $ perf_new report -i perf_new.data --header-only -I
  ......
  # sibling threads : 33
  # sibling threads : 34
  # sibling threads : 35
  # CPU 0: Core ID 0, Socket ID 0
  # CPU 1: Core ID 1, Socket ID 0
  ......
  # CPU 61: Core ID 10, Socket ID 1
  # CPU 62: Core ID 11, Socket ID 1
  # CPU 63: Core ID 16, Socket ID 1
  # node0 meminfo  : total = 32823872 kB, free = 29190932 kB
  # node0 cpu list : 0-17,36-53

Signed-off-by: Kan Liang 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Link: http://lkml.kernel.org/r/1441115893-22006-2-git-send-email-kan.liang@intel.com
Signed-off-by: Arnaldo Carvalho de Melo