When annotating source/disasm lines the perf tools parse the output of
objdump, trying to provide augmented output that allows navigating
jumps, calls, etc.
But when a line output by objdump can't be parsed the annotation code
falls back to just presenting the unparsed line.
When fixing a leak in the 0fb9f2aab7 commit ("perf annotate: Fix
memory leaks in LOCK handling") we failed to take that into account and
instead tried to free one of the data structures that should be freed
only when successfully allocated, oops, segfault.
There was a change in the way the objdump output for lock prefixed
instructions is formatted that lead the relevant parser to fail to grok
it.
At least RHEL7 works ok, but Fedora 20 segfaults.
Fix it by making the ins__delete() destructor work like the most basic
destructor: free().
Namely make it accept a NULL pointer and when handling it just do
nothing.
Further investigation is needed to figure out the nature of the objdump
output change so as to make the parser grok it.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Rabin Vincent <rabin@rab.in>
Link: http://lkml.kernel.org/n/tip-7wsy0zo292pif0yjoqpfryrz@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf-top is terminating due to SIGBUS on sparc64. git bisect points to:
commit 8239698603
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Mon Sep 8 13:26:35 2014 -0300
perf evlist: Refcount mmaps
We need to know how many fds are using a perf mmap via
PERF_EVENT_IOC_SET_OUTPUT, so that we can know when to ditch an mmap,
refcount it.
This commit added 'int refcnt' to struct perf_mmap and the addition makes the
event_copy element no longer 8-byte aligned.
Fix by adding __attribute__((aligned(8))) to the event_copy struct
member.
Signed-off-by: David Ahern <david.ahern@oracle.com>
Link: http://lkml.kernel.org/r/1424304198-92028-1-git-send-email-david.ahern@oracle.com
[ Switched from 'int pad;' to using __attribute__, David tested/acked that ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Commit f6edb53c49 converted the probe to
a CPU wide event first (pid == -1). For kernels that do not support
the PERF_FLAG_FD_CLOEXEC flag the probe fails with EINVAL. Since this
errno is not handled pid is not reset to 0 and the subsequent use of
pid = -1 as an argument brings in an additional failure path if
perf_event_paranoid > 0:
$ perf record -- sleep 1
perf_event_open(..., 0) failed unexpectedly with error 13 (Permission denied)
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.007 MB /tmp/perf.data (11 samples) ]
Also, ensure the fd of the confirmation check is closed and comment why
pid = -1 is used.
Needs to go to 3.18 stable tree as well.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Based-on-patch-by: David Ahern <david.ahern@oracle.com>
Acked-by: David Ahern <david.ahern@oracle.com>
Cc: David Ahern <dsahern@gmail.com>
Link: http://lkml.kernel.org/r/54EC610C.8000403@intel.com
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The perf_event_attr.task bit is to track task (fork and exit) events but
it missed to be set by perf_evsel__config(). While it was not a problem
in practice since setting other bits (comm/mmap) ended up being in same
result, it'd be good to set it explicitly anyway.
The attr->task is to track task related events (fork/exit) only but
other meta events like comm and mmap[2] also needs the task events. So
setting attr->comm and/or attr->mmap causes the kernel emits the task
events anyway. So the attr->task is only meaningful when other bits are
off but I'd like to set it for completeness.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/r/1422518843-25818-6-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When running perf on ARC (uClibc based userspace), ran into this issue
------------->8----------------
[ARCLinux]$ ./perf record ls
bin etc perf sys
debug init perf.data tmp
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.001 MB perf.data (~24 samples) ]
[ARCLinux]$ ./perf report
incompatible file format (rerun with -v to learn more)
------------->8----------------
The problem happens in the following call stack when zalloc is called
with size zero
glibc default / uClibc with MALLOC_GLIBC_COMPAT are OK, but not if that
config option is not enabled.
cmd_report
perf_session__new
perf_session__open
perf_session__read_header
read_attr(fd, header, &f_attr)
nr_ids = f_attr.ids.size / sizeof(u64); <-- 0
perf_evsel__alloc_id(vsel, 1, nr_ids)
zalloc(ncpus * nthreads * sizeof(u64)) <-- 0
header.c: read_attr()
(gdb) p *f_attr
$17 = {
attr = {
type = 0,
size = 96,
config = 0,
{
sample_period = 4000,
sample_freq = 4000
},
...
ids = {
offset = 104,
size = 0 <------
}
}
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Suggested-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1421156604-30603-5-git-send-email-vgupta@synopsys.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The new hw_breakpoint bits are now ready for v3.20, merge them
into the main branch, to avoid conflicts.
Conflicts:
tools/perf/Documentation/perf-record.txt
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The commit dfef99cd0b ("perf probe: Use ref_reloc_sym based address
instead of the symbol name") converts kprobes to use ref_reloc_sym (i.e.
_stext) and offset instead of using symbol's name directly. So on my
system, adding do_fork ends up with like below:
$ sudo perf probe -v --add do_fork%return
probe-definition(0): do_fork%return
symbol:do_fork file:(null) line:0 offset:0 return:1 lazy:(null)
0 arguments
Looking at the vmlinux_path (7 entries long)
Using /lib/modules/3.17.6-1-ARCH/build/vmlinux for symbols
Could not open debuginfo. Try to use symbols.
Opening /sys/kernel/debug/tracing/kprobe_events write=1
Added new event:
Writing event: r:probe/do_fork _stext+456136
Failed to write event: Invalid argument
Error: Failed to add events. Reason: Operation not permitted (Code: -1)
As you can see, the do_fork was translated to _stext+456136. This was
because to support (local) symbols that have same name. But the problem
is that kretprobe requires to be inserted at function start point so it
simply checks whether it's called with offset 0. And if not, it'll
return with -EINVAL. You can see it with dmesg.
$ dmesg | tail -1
[125621.764103] Return probe must be used without offset.
So we need to use the symbol name instead of ref_reloc_sym in case of
return probes.
Reported-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Jiri Olsa <jolsa@redhat.com>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: David Ahern <dsahern@gmail.com>
Link: http://lkml.kernel.org/r/1421234288-22758-4-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The find_probe_trace_events_from_map() searches matching symbol from a
map (so from a backing dso). For uprobes, it'll create a new map (and
dso) and loads it using a filter. It's a little bit inefficient in that
it'll read out the symbol table everytime but works well anyway.
For kprobes however, it'll reuse existing kernel map which might be
loaded before. In this case map__load() just returns with no result.
It makes kprobes always failed to find symbol even if it exists in the
map (dso).
To fix it, use map__find_symbol_by_name() instead. It'll load a map
with full symbols and sorts them by name. It needs to search sibing
nodes since there can be multiple (local) symbols with same name.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Link: http://lkml.kernel.org/r/1421234288-22758-3-git-send-email-namhyung@kernel.org
[ Use symbol__next_by_name ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When a dso contains multiple symbols which have same name, current
dso__find_symbol_by_name() only finds an one of them and there's no way
to get the all symbols without going through the rbtree.
So make symbols__find_by_name() return the first entry with the given
name and the next patch in this series will provide a way to iterate
from there, by the name ordered rb_tree, till a suitable symbol is
found.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Link: http://lkml.kernel.org/r/1421234288-22758-2-git-send-email-namhyung@kernel.org
[ Yanked this independent hunk, without changes, from a larger patch ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Currently the symbol structure is allocated with symbol_conf.priv_size
to carry sideband information like annotation, map browser on TUI and
sort-by-name tree node. So retrieving these information from symbol
needs to care about the details of such placement.
However the annotation code just assumes that the symbol is placed after
the struct annotation. But actually there's other info between them.
So accessing those struct will lead to an undefined behavior (usually a
crash) after they write their info to the same location.
To reproduce the problem, please follow the steps below:
1. run perf report (TUI of course) with -v option
2. open map browser (by pressing right arrow key for any entry)
3. search any function (by pressing '/' key and input whatever..)
4. return to the hist browser (by pressing 'q' or left arrow key)
5. open annotation window for the same entry (by pressing 'a' key)
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1421234288-22758-1-git-send-email-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Perf tool fails to unwind user stack if the event raises in a shared
object. This patch improves tests/dwarf-unwind.c to demonstrate the
problem by utilizing commonly used glibc function "bsearch". If perf is
not statically linked, the testcase will try to unwind a mixed call
trace.
By debugging libunwind I found that there is a bug in unwind-libunwind:
it always passes 0 as segbase to libunwind, cause libunwind unable to
locate debug_frame entry fir first level ip address (I add some more
debugging output into libunwind to make things clear):
>_Uarm_dwarf_find_debug_frame: start_ip = 10be98, end_ip = 10c2a4
>_Uarm_dwarf_find_debug_frame: found debug_frame table `/lib/libc-2.18.so': segbase=0x0, len=7, gp=0x0, table_data=0x449388
>_Uarm_dwarf_search_unwind_table: call lookup:ip = b6cd3bcc, segbase = 0, rel_ip = b6cd3bcc
>lookup: e->start_ip_offset = bcf18 (rel_ip = b6cd3bcc)
>lookup: e->start_ip_offset = 6d314 (rel_ip = b6cd3bcc)
>lookup: e->start_ip_offset = 33d0c (rel_ip = b6cd3bcc)
...
>lookup: e->start_ip_offset = 15d0c (rel_ip = b6cd3bcc)
>lookup: e->start_ip_offset = 15c40 (rel_ip = b6cd3bcc)
>_Uarm_dwarf_search_unwind_table: IP b6cd3bcc inside range b6c12000-b6d4c000, but no explicit unwind info found
>put_rs_cache: unmasking signals/interrupts and releasing lock
>_Uarm_dwarf_step: returning -10
>_Uarm_step: dwarf_step()=-10
This patch passes map->start as segbase to dwarf_find_debug_frame(), so
di will be initialized correctly.
In addition, dso and executable are different when setting segbase. This
patch first check whether the elf is executable, and pass segbase only
for shared object.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1421203007-75799-1-git-send-email-wangnan0@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
----------------->8------------------
CC bench/sched-pipe.o
In file included from builtin-annotate.c:13:0:
util/cache.h:76:15: warning: redundant redeclaration of 'strlcpy'
[-Wredundant-decls]
extern size_t strlcpy(char *dest, const char *src, size_t size);
^
In file included from util/util.h:55:0,
from builtin.h:4,
from builtin-annotate.c:8:
~/vineetg/arc/gnu/INSTALL_1412-arc-2014.12-rc1/arc-snps-linux-uclibc/sysroot/usr/include/string.h:396:15:
note: previous declaration of 'strlcpy' was here
extern size_t strlcpy(char *__restrict dst, const char *__restrict src,
----------------->8------------------
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1421156604-30603-3-git-send-email-vgupta@synopsys.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
David reported that perf can segfault when adding an uprobe event like
this:
$ perf probe -x /lib64/libc-2.14.90.so -a 'malloc size=%di'
(gdb) bt
#0 parse_eh_frame_hdr (hdr=0x0, hdr_size=2596, hdr_vaddr=71788,
ehdr=0x7fffffffd390, eh_frame_vaddr=
0x7fffffffd378, table_entries=0x8808d8, table_encoding=0x8808e0 "") at
dwarf_getcfi_elf.c:79
#1 0x000000385f81615a in getcfi_scn_eh_frame (hdr_vaddr=71788,
hdr_scn=0x8839b0, shdr=0x7fffffffd2f0, scn=<optimized out>,
ehdr=0x7fffffffd390, elf=0x882b30) at dwarf_getcfi_elf.c:231
#2 getcfi_shdr (ehdr=0x7fffffffd390, elf=0x882b30) at dwarf_getcfi_elf.c:283
#3 dwarf_getcfi_elf (elf=0x882b30) at dwarf_getcfi_elf.c:309
#4 0x00000000004d5bac in debuginfo__find_probes (pf=0x7fffffffd4f0,
dbg=Unhandled dwarf expression opcode 0xfa) at util/probe-finder.c:993
#5 0x00000000004d634a in debuginfo__find_trace_events (dbg=0x880840,
pev=<optimized out>, tevs=0x880f88, max_tevs=<optimized out>) at
util/probe-finder.c:1200
#6 0x00000000004aed6b in try_to_find_probe_trace_events (target=0x881b20
"/lib64/libpthread-2.14.90.so",
max_tevs=128, tevs=0x880f88, pev=0x859b30) at util/probe-event.c:482
#7 convert_to_probe_trace_events (target=0x881b20
"/lib64/libpthread-2.14.90.so", max_tevs=128, tevs=0x880f88,
pev=0x859b30) at util/probe-event.c:2356
#8 add_perf_probe_events (pevs=<optimized out>, npevs=1, max_tevs=128,
target=0x881b20 "/lib64/libpthread-2.14.90.so", force_add=false) at
util/probe-event.c:2391
#9 0x000000000044014f in __cmd_probe (argc=<optimized out>,
argv=0x7fffffffe2f0, prefix=Unhandled dwarf expression opcode 0xfa) at
at builtin-probe.c:488
#10 0x0000000000440313 in cmd_probe (argc=5, argv=0x7fffffffe2f0,
prefix=<optimized out>) at builtin-probe.c:506
#11 0x000000000041d133 in run_builtin (p=0x805680, argc=5,
argv=0x7fffffffe2f0) at perf.c:341
#12 0x000000000041c8b2 in handle_internal_command (argv=<optimized out>,
argc=<optimized out>) at perf.c:400
#13 run_argv (argv=<optimized out>, argcp=<optimized out>) at perf.c:444
#14 main (argc=5, argv=0x7fffffffe2f0) at perf.c:559
And I found a related commit (5704c8c4fa71 "getcfi_scn_eh_frame: Don't
crash and burn when .eh_frame bits aren't there.") in elfutils that can
lead to a unexpected crash like this. To safely use the function, it
needs to check the .eh_frame section is a PROGBITS type.
Reported-by: David Ahern <dsahern@gmail.com>
Tested-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Mark Wielaard <mjw@redhat.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Link: http://lkml.kernel.org/r/20141230090533.GH6081@sejong
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Fix to fall back to find a probe point in symbols if perf fails to find
it in debuginfo.
This can happen when the target function is an alias of another
function. Such alias doesn't have an entry in debuginfo but in symbols.
David Ahern reported this problem in https://lkml.org/lkml/2014/12/29/355
I ensured the problem and deeper investigation discovers it.
-----
eu-readelf --debug-dump=info /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so | grep \"malloc\" -A6
name (strp) "malloc"
decl_file (data1) 25
decl_line (data2) 466
prototyped (flag_present)
type (ref4) [ 81b5]
declaration (flag_present)
[ 8f58] formal_parameter
--
name (strp) "malloc"
decl_file (data1) 23
decl_line (data2) 466
prototyped (flag_present)
type (ref4) [ 9f4a]
declaration (flag_present)
sibling (ref4) [ bb29]
...
-----
All these entires have no instances (all of them are declarations)
This is why the perf probe failed to find it in debuginfo.
However, there are some malloc instances in symbols.
-----
eu-readelf --symbols /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so | grep malloc$
1181: 0000000000080700 5332 FUNC LOCAL DEFAULT 12 _int_malloc
4537: 00000000000831d0 339 FUNC LOCAL DEFAULT 12 __GI___libc_malloc
5545: 00000000000831d0 339 FUNC LOCAL DEFAULT 12 __malloc
6063: 00000000000831d0 339 FUNC GLOBAL DEFAULT 12 malloc
7302: 00000000000831d0 339 FUNC GLOBAL DEFAULT 12 __libc_malloc
-----
As you an see, malloc and __libc_malloc have same address, and actually
__libc_malloc has an entry in debuginfo. So you can set up a probe on
__libc_malloc.
To fix this problem shortly, perf probe simply falls back to find probe
point(malloc) in symbols if it is not found in debuginfo.
Reported-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: yrl.pp-manager.tt@hitachi.com
Link: http://lkml.kernel.org/r/20141231062747.2087.80961.stgit@localhost.localdomain
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Pull perf/urgent fixes from Arnaldo Carvalho de Melo:
User visible fixes:
- Show progress bar in more places while doing histogram processing
in the hists browser (Namhyung Kim)
- Print backtrace symbols when segfault occurs in 'report' (Namhyung Kim)
Infrastructure fixes:
- Append callchains only when requested (Namhyung Kim)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Pull perf fixes and cleanups from Ingo Molnar:
"A kernel fix plus mostly tooling fixes, but also some tooling
restructuring and cleanups"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (39 commits)
perf: Fix building warning on ARM 32
perf symbols: Fix use after free in filename__read_build_id
perf evlist: Use roundup_pow_of_two
tools: Adopt roundup_pow_of_two
perf tools: Make the mmap length autotuning more robust
tools: Adopt rounddown_pow_of_two and deps
tools: Adopt fls_long and deps
tools: Move bitops.h from tools/perf/util to tools/
tools: Introduce asm-generic/bitops.h
tools lib: Move asm-generic/bitops/find.h code to tools/include and tools/lib
tools: Whitespace prep patches for moving bitops.h
tools: Move code originally from asm-generic/atomic.h into tools/include/asm-generic/
tools: Move code originally from linux/log2.h to tools/include/linux/
tools: Move __ffs implementation to tools/include/asm-generic/bitops/__ffs.h
perf evlist: Do not use hard coded value for a mmap_pages default
perf trace: Let the perf_evlist__mmap autosize the number of pages to use
perf evlist: Improve the strerror_mmap method
perf evlist: Clarify sterror_mmap variable names
perf evlist: Fixup brown paper bag on "hint" for --mmap-pages cmdline arg
perf trace: Provide a better explanation when mmap fails
...
Commit 85c116a6cb ("perf callchain: Make get_srcline fall back to sym+offset")
introduces asprintf() call and matches '%ld' to a u64 argument, which is
incorrect on ARM:
CC /home/wn/util/srcline.o
util/srcline.c: In function 'get_srcline':
util/srcline.c:297:6: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'u64' [-Werror=format]
cc1: all warnings being treated as errors
make[1]: *** [/home/wn/util/srcline.o] Error 1
In addition, all users of get_srcline() use u64 addr, and libbfd
also use 64 bit bfd_vma as address. This patch also fix
prototype of get_srcline() and addr2line() to use u64 addr
instead of unsigned long.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Namhyung Kim <namhyung@kernel.org>
Cc: <lizefan@huawei.com>
Cc: <a.p.zijlstra@chello.nl>
Cc: <paulus@samba.org>
Cc: <acme@kernel.org>
Cc: <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1418710746-35943-1-git-send-email-wangnan0@huawei.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
If /proc/sys/kernel/perf_event_mlock_kb is not (power of 2 + PAGE_SIZE_in_kb)
and we let the perf tools do mmap length autosizing based on that, then, for
non-CAP_IPC_LOCK users when /proc/sys/kernel/perf_event_paranoid is > -1, then
we get an -EINVAL that ends up in:
[acme@ssdandy linux]$ trace usleep 1
Invalid argument
[acme@ssdandy linux]$ perf record usleep 1
failed to mmap with 22 (Invalid argument)
After this fix:
[acme@ssdandy linux]$ trace usleep 1
<SNIP>
0.806 ( 0.006 ms): munmap(addr: 0x7f7e4740a000, len: 66467) = 0
0.869 ( 0.002 ms): brk( ) = 0x7bb000
0.873 ( 0.003 ms): brk(brk: 0x7dc000 ) = 0x7dc000
0.877 ( 0.001 ms): brk( ) = 0x7dc000
0.953 ( 0.058 ms): nanosleep(rqtp: 0x7fff26ab9420 ) = 0
0.959 ( 0.000 ms): exit_group(
[acme@ssdandy linux]$ perf record usleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.017 MB perf.data (~759 samples) ]
[acme@ssdandy linux]$
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: David Ahern <dsahern@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lkml.kernel.org/n/tip-6p6l5ou6jev6o7ymc4nn1n2a@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
