linux-stable.git/tools/perf/util/vdso.c, branch linux-4.2.y

perf tools: Fix lockup using 32-bit compat vdso

2015-07-07T14:05:08+00:00

The __machine__findnew_compat() function is called only from
__machine__findnew_vdso_compat() which is called only from
machine__findnew_vdso() which already holds machine->dsos.lock, so
remove locking from __machine__findnew_compat().

This manifests itself tracing 32-bit programs with a 64-bit perf.

Signed-off-by: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/r/1436267618-20521-1-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Reference count struct dso

2015-06-08T13:31:40+00:00

This has a different model than the 'thread' and 'map' struct lifetimes:
there is not a definitive "don't use this DSO anymore" event, i.e. we may
get many 'struct map' holding references to the '/usr/lib64/libc-2.20.so'
DSO but then at some point some DSO may have no references but we still
don't want to straight away release its resources, because "soon" we may
get a new 'struct map' that needs it and we want to reuse its symtab or
other resources.

So we need some way to garbage collect it when crossing some memory
usage threshold, which is left for anoter patch, for now it is
sufficient to release it when calling dsos__exit(), i.e. when deleting
the whole list as part of deleting the 'struct machine' containing it,
which will leave only referenced objects being used.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/n/tip-majzgz07cm90t2tejrjy4clf@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Protect accesses the dso rbtrees/lists with a rw lock

2015-06-08T13:31:40+00:00

To allow concurrent access, next step: refcount struct dso instances, so
that we can ditch unused them when the last map pointing to it goes
away.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/n/tip-yk1k08etpd2aoe3tnrf0oizn@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf machine: Fix up vdso methods names

2015-05-29T15:43:44+00:00

To make it consistent with the other dso lifetime routines.

For instance:

 struct dso *vdso__new(struct machine *machine, const char *short_name,
		        const char *long_name)

Becomes:

 struct dso *machine__addnew_vdso(struct machine *machine, const
				  char *short_name, const char *long_name)

Because:

1) There is no 'struct vdso' for us to have vdso__ prefixed routines.

2) Because it will not really just create a new instance of 'struct
   dso', it'll call dso__new() but it will also insert it into the
   DSO's list/rbtree, and we have a method name for that: 'addnew',
   just like we have dsos__addnew().

3) So it is really a 'struct machine' operation, it is the first
   argument, etc.

This way the place where this is used gets consistent:

                if (vdso) {
                        pgoff = 0;
-                       dso = vdso__dso_findnew(machine, thread);
+                       dso = machine__findnew_vdso(machine, thread);
                } else
                        dso = machine__findnew_dso(machine, filename);

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Link: http://lkml.kernel.org/n/tip-r3w3tvh8exm9xfz3p4tz9qbz@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf machine: No need to have two DSOs lists

2015-05-29T15:43:43+00:00

We can, given a DSO, figure out if it is a kernel, a kernel module or
a userlevel DSO, so stop having to process two lists in several
functions.

If searching becomes an issue at some point, we can have them in a
rbtree, etc.

Cc: Adrian Hunter 
Cc: Borislav Petkov 
Cc: David Ahern 
Cc: Don Zickus 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/n/tip-s4yb0onpdywu6dj2xl9lxi4t@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Do not attempt to run perf-read-vdso32 if it wasn't built

2014-10-29T12:32:48+00:00

popen() causes an error message to print if perf-read-vdso32 does not
run.  Avoid that by not trying to run it if it was not built.  Ditto
perf-read-vdsox32.

Signed-off-by: Adrian Hunter 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/r/1414061124-26830-17-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Add support for 32-bit compatibility VDSOs

2014-10-29T12:32:48+00:00

'perf record' post-processes the event stream  to create a list of
build-ids for object files for which sample events have been recorded.
That results in those object files being recorded in the build-id cache.

In the case of VDSO, perf tools reads it from memory and copies it into
a temporary file, which as decribed above, gets added to the build-id
cache.

Then when the perf.data file is processed by other tools, the build-id
of VDSO is listed in the perf.data file and the VDSO can be read from
the build-id cache.  In that case the name of the map, the short name of
the DSO, and the entry in the build-id cache are all "[vdso]".

However, in the 64-bit case, there also can be 32-bit compatibility
VDSOs.

A previous patch added programs "perf-read-vdso32" and "perf
read-vdsox32".

This patch uses those programs to read the correct VDSO for a thread and
create a temporary file just as for the 64-bit VDSO.

The map name and the entry in the build-id cache are still "[vdso]" but
the DSO short name becomes "[vdso32]" and "[vdsox32]" respectively.

Signed-off-by: Adrian Hunter 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/r/1414061124-26830-16-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Build programs to copy 32-bit compatibility

2014-10-29T12:32:48+00:00

perf tools copy VDSO out of memory.  However, on 64-bit machines there
may be 32-bit compatibility VDOs also.  To copy those requires separate
32-bit executables.

This patch adds to the build additional programs perf-read-vdso32 and
perf-read-vdsox32 for 32-bit and x32 respectively.

Signed-off-by: Adrian Hunter 
Cc: Peter Zijlstra 
Cc: David Ahern 
Cc: Frederic Weisbecker ,
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/r/1414061124-26830-15-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Add thread parameter to vdso__dso_findnew()

2014-07-23T20:37:26+00:00

The thread will be needed to determine the VDSO type.

Reviewed-by: Jiri Olsa 
Signed-off-by: Adrian Hunter 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/r/1406035081-14301-52-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo

perf tools: Separate the VDSO map name from the VDSO dso name

2014-07-23T20:36:32+00:00

This is in preparation for supporting 32-bit compatibility VDSOs.

Reviewed-by: Jiri Olsa 
Signed-off-by: Adrian Hunter 
Cc: David Ahern 
Cc: Frederic Weisbecker 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lkml.kernel.org/r/1406035081-14301-49-git-send-email-adrian.hunter@intel.com
Signed-off-by: Arnaldo Carvalho de Melo