- 09 Dec, 2009 13 commits
-
-
Frederic Weisbecker authored
When we define the common event fields in kprobe, we invert the error handling and return immediately in case of success. Then we omit to define specific kprobes fields (ip and nargs), and specific kretprobes fields (func, ret_ip, nargs). And we only define them when we fail to create common fields. The most visible consequence is that we can't create filter for k(ret)probes specific fields. This patch re-invert the success/error handling to fix it. Reported-by:
Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by:
Frederic Weisbecker <fweisbec@gmail.com> Acked-by:
Masami Hiramatsu <mhiramat@redhat.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Li Zefan <lizf@cn.fujitsu.com> LKML-Reference: <1260263815-5167-1-git-send-regression-fweisbec@gmail.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu>
-
Xiao Guangrong authored
Using atomic64_xchg() instead of atomic64_read() and atomic64_set(). Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Reviewed-by:
-
Xiao Guangrong authored
In current code, children task will allocate memory for 'child->perf_event_ctxp' if the parent is counted, we can do it only if the parent allowed children inherit it. It can save memory and reduce overhead. Signed-off-by:
-
Xiao Guangrong authored
Clean up the code a bit: - define 'perf_cpu_context' variable with 'static' - use kzalloc() instead of kmalloc() and memset() Signed-off-by:
-
Frederic Weisbecker authored
Currently, when ptrace needs to modify a breakpoint, like disabling it, changing its address, type or len, it calls modify_user_hw_breakpoint(). This latter will perform the heavy and racy task of unregistering the old breakpoint and registering a new one. This is racy as someone else might steal the reserved breakpoint slot under us, which is undesired as the breakpoint is only supposed to be modified, sometimes in the middle of a debugging workflow. We don't want our slot to be stolen in the middle. So instead of unregistering/registering the breakpoint, just disable it while we modify its breakpoint fields and re-enable it after if necessary. Signed-off-by:
-
Masami Hiramatsu authored
Add --list and --del option descriptions to perf-probe.txt. Signed-off-by:
-
Masami Hiramatsu authored
Support perf probe --del <event> option. Currently, perf probe can have only one event for each --del option. If you'd like to delete several probe events, you need to specify --del for each events. Signed-off-by:
-
Masami Hiramatsu authored
Support delete probe syntax. The syntax is "-:[group/]event". Signed-off-by:
-
Masami Hiramatsu authored
Support vmlinux on current working direcotry by default and also update file-open messages. Now perf probe searches ./vmlinux too. Signed-off-by:
-
Masami Hiramatsu authored
Remove event suffix number _0 if it is the first. The first event has no suffix, and from the second, each event has suffix number counted from _1. This reduces typing cost :-). Signed-off-by:
-
Masami Hiramatsu authored
Fix add-probe command syntax without --add option. perf-probe supports add-probe command without --add option. But it treats each argument as an event definition. e.g. perf probe func arg1 arg2 is interpreted as perf probe --add func --add arg1 --add arg2 But it may be useless in many cases. This patch fixes this syntax to fold those arguments into one event definition if there is no --add option. With this change, above command is interpreted as below; perf probe --add "func arg1 arg2" Signed-off-by:
-
Masami Hiramatsu authored
Change probe-added message more user-friendly expression and show usage of new events. Before: Added new event: p:probe/schedule_0 schedule+10 prev=%ax cpu=%bx After: Added new event: probe:schedule_1 (on schedule+1 with prev cpu) You can now use it on all perf tools, such as: perf record -e probe:schedule_1 -a sleep 1 Signed-off-by: -
Masami Hiramatsu authored
Change event list format for user readability. perf probe --list shows event list in "[GROUP:EVENT] EVENT-DEFINITION" format, but this format is different from the output of perf-list, and EVENT-DEFINITION is a bit blunt. This patch changes the format to more user friendly one. Before: [probe:schedule_0] schedule+10 prev cpu After: probe:schedule_0 (on schedule+10 with prev cpu) Signed-off-by:
-
- 08 Dec, 2009 2 commits
-
-
Stephen Rothwell authored
Today's linux-next build failed with: kernel/hw_breakpoint.c:86: error: 'task_bp_pinned' redeclared as different kind of symbol ... Caused by commit dd17c8f7 ("percpu: remove per_cpu__ prefix") from the percpu tree interacting with commit 56053170 ("hw-breakpoints: Fix task-bound breakpoint slot allocation") from the tip tree. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Acked-by:
-
Arnd Bergmann authored
asm/hw_breakpoint.h is evidently a kernel internal file and should not be included globally, not even under an #ifdef. Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: K.Prasad <prasad@linux.vnet.ibm.com> LKML-Reference: <200912071712.58650.arnd@arndb.de> Signed-off-by:
-
- 07 Dec, 2009 16 commits
-
-
Masami Hiramatsu authored
Use pr_debug() for "missing vmlinux" debugging message. Signed-off-by:
-
Masami Hiramatsu authored
Check e_snprintf() format string by gcc, and fix a bug of e_snprintf() caller. Signed-off-by:
-
Masami Hiramatsu authored
Fix event namelist to duplicate string. Without duplicating, adding multiple probes causes stack overwrite bug, because it reuses a buffer on stack while the buffer is already added in the namelist. String duplication solves this bug because only contents of the buffer is copied to the namelist. Signed-off-by:
-
Juha Leppanen authored
Fix strtailcmp() to compare s1[0] and s2[0]. strtailcmp() returns 0 if "a" and "b" or "a" and "ab", it's a wrong behavior. This patch fixes it. Signed-off-by:
"Juha Leppanen" <juha_motorsportcom@luukku.com> Acked-by:
-
Masami Hiramatsu authored
Delete empty or incomplete inat-tables.c if gen-insn-attr-x86.awk failed, because it causes a build error if user tries to build kernel next time. Reported-by:
Arkadiusz Miskiewicz <arekm@maven.pl> Signed-off-by:
-
OGAWA Hirofumi authored
At least, insn.c and inat.c is needed for kprobe for now. So, this compile those only if KPROBES is enabled. Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Masami Hiramatsu <mhiramat@redhat.com> LKML-Reference: <878wdg8icq.fsf@devron.myhome.or.jp> Signed-off-by:
-
Ulrich Drepper authored
Uses of strcat are almost always signs that someone is too lazy to think about the code a bit more carefully. One always has to know about the lengths of the strings involved to avoid buffer overflows. This is one case where the size of the object code for me is reduced by 38 bytes. The code should also be faster, especially if flags is non-NULL. Signed-off-by:
Ulrich Drepper <drepper@redhat.com> Cc: a.p.zijlstra@chello.nl Cc: fweisbec@gmail.com Cc: jaswinderrajput@gmail.com Cc: paulus@samba.org LKML-Reference: <200912061825.nB6IPUa1023306@hs20-bc2-1.build.redhat.com> Signed-off-by:
-
Tom Zanussi authored
The 'scripting unsupported' message should only be displayed when the -s or -g options are used, and not when they aren't, as the current code does. Signed-off-by:
Tom Zanussi <tzanussi@gmail.com> Cc: rostedt@goodmis.org Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Mike Galbraith <efault@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> LKML-Reference: <1260163919-6679-3-git-send-email-tzanussi@gmail.com> Signed-off-by:
-
Ingo Molnar authored
Merge branch 'perf/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing into perf/urgent
-
Frederic Weisbecker authored
Whatever the context nature of a breakpoint, we always perform the following constraint checks before allocating it a slot: - Check the number of pinned breakpoint bound the concerned cpus - Check the max number of task-bound breakpoints that are belonging to a task. - Add both and see if we have a reamining slot for the new breakpoint This is the right thing to do when we are about to register a cpu-only bound breakpoint. But not if we are dealing with a task bound breakpoint. What we want in this case is: - Check the number of pinned breakpoint bound the concerned cpus - Check the number of breakpoints that already belong to the task in which the breakpoint to register is bound to. - Add both This fixes a regression that makes the "firefox -g" command fail to register breakpoints once we deal with a secondary thread. Reported-by:
Walt <w41ter@gmail.com> Signed-off-by:
-
Frederic Weisbecker authored
The perf attrs used to set up breakpoint parameters are often allocated in the stack and not zeroed out before calling hw_breakpoint_init(). Handle it from this helper to avoid random attributes set by the stack. Signed-off-by: -
Tom Zanussi authored
When I added the xs callbacks into perf, I forgot to re-check the no-libperl case. This patch fixes the undefined reference error for that. Reported-by:
Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Signed-off-by:
-
Xiao Guangrong authored
raw->size is not used, this patch just cleans it up. Signed-off-by:
-
Xiao Guangrong authored
The remain buff size is 'len - pos->long_name_len - 1', not 'len - pos->long_name_len + 1' This bug was introduced by commit 7691b1ec ("perf tools: Misc small fixes"). Signed-off-by:
-
Xiao Guangrong authored
We use 'data.raw_data' parameter to call process_raw_event(), but data.raw_data buffer not include data size. it can make perf tool crash. This bug was introduced by commit 180f95e2 ("perf: Make common SAMPLE_EVENT parser"). Signed-off-by:
-
Xiao Guangrong authored
If we use 'perf sched trace', it will call symbol__init() again, and can lead to a perf tool crash: [root@localhost perf]# ./perf sched trace *** glibc detected *** ./perf: free(): invalid next size (normal): 0x094c1898 *** ======= Backtrace: ========= /lib/libc.so.6[0xb7602404] /lib/libc.so.6(cfree+0x96)[0xb76043b6] ./perf[0x80730fe] ./perf[0x8074c97] ./perf[0x805eb59] ./perf[0x80536fd] ./perf[0x804b618] ./perf[0x804bdc3] /lib/libc.so.6(__libc_start_main+0xe5)[0xb75a9735] ./perf[0x804af81] ======= Memory map: ======== 08048000-08158000 r-xp 00000000 fe:00 556831 /home/eric/.... 08158000-08168000 rw-p 0010f000 fe:00 556831 /home/eric/... 08168000-085fe000 rw-p 00000000 00:00 0 094ab000-094cc000 rw-p 00000000 00:00 0 [heap] Signed-off-by:
-
- 06 Dec, 2009 9 commits
-
-
Arnaldo Carvalho de Melo authored
Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frédéric Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> LKML-Reference: <1260129790-11520-1-git-send-email-acme@infradead.org> Signed-off-by:
-
OGAWA Hirofumi authored
- util/header.c "len" is aligned to 64. So, it tries to write the out of long_name buffer. So, this use "zero_buf" to write aligned area. - util/trace-event-read.c "size" is not including nul byte. So, this allocates it, and set '\0'. - util/trace-event-parse.c It needs parens to calc correct size. Signed-off-by:
-
OGAWA Hirofumi authored
Currently, sample event data is parsed for each commands, and it is assuming that the data is not including other data. (E.g. timechart, trace, etc. can't parse the event if it has PERF_SAMPLE_CALLCHAIN) So, even if we record the superset data for multiple commands at a time, commands can't parse. etc. To fix it, this makes common sample event parser, and use it to parse sample event correctly. (PERF_SAMPLE_READ is unsupported for now though, it seems to be not using.) Signed-off-by:
-
OGAWA Hirofumi authored
Update "struct trace_entry" to match with current one. And remove "size" field from it. If it has "size", it become cause of alignment mismatch of structure with kernel. Signed-off-by:
Arjan van de Ven <arjan@infradead.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> LKML-Reference: <87ljhg8ioe.fsf@devron.myhome.or.jp> Signed-off-by:
-
Jean Delvare authored
Fix the following warning: arch/x86/tools/test_get_len.c: In function "main": arch/x86/tools/test_get_len.c:116: warning: unused variable "c" Signed-off-by:
Jean Delvare <khali@linux-fr.org> Cc: Masami Hiramatsu <mhiramat@redhat.com> Signed-off-by:
-
Julia Lawall authored
The size argument to zalloc should be the size of desired structure, not the pointer to it. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @expression@ expression *x; @@ x = <+... -sizeof(x) +sizeof(*x) ...+>// </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Mike Galbraith <efault@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> LKML-Reference: <Pine.LNX.4.64.0912061016120.20858@ask.diku.dk> Signed-off-by:
-
Frederic Weisbecker authored
When we enter in irq, two things can happen to preserve the link to the previous frame pointer: - If we were in an irq already, we don't switch to the irq stack as we are inside. We just need to save the previous frame pointer and to link the new one to the previous. - Otherwise we need another level of indirection. We enter the irq with the previous stack. We save the previous bp inside and make bp pointing to its saved address. Then we switch to the irq stack and push bp another time but to the new stack. This makes two levels to dereference instead of one. In the second case, the current stacktrace code omits the second level and loses the frame pointer accuracy. The stack that follows will then be considered as unreliable. Handling that makes the perf callchain happier. Before: 43.94% [k] _raw_read_lock | --- _read_lock | |--60.53%-- send_sigio | __kill_fasync | kill_fasync | evdev_pass_event | evdev_event | input_pass_event | input_handle_event | input_event | synaptics_process_byte | psmouse_handle_byte | psmouse_interrupt | serio_interrupt | i8042_interrupt | handle_IRQ_event | handle_edge_irq | handle_irq | __irqentry_text_start | ret_from_intr | | | |--30.43%-- __select | | | |--17.39%-- 0x454f15 | | | |--13.04%-- __read | | | |--13.04%-- vread_hpet | | | |--13.04%-- _xcb_lock_io | | | --13.04%-- 0x7f630878ce8 After: 50.00% [k] _raw_read_lock | --- _read_lock | |--98.97%-- send_sigio | __kill_fasync | kill_fasync | evdev_pass_event | evdev_event | input_pass_event | input_handle_event | input_event | | | |--96.88%-- synaptics_process_byte | | psmouse_handle_byte | | psmouse_interrupt | | serio_interrupt | | i8042_interrupt | | handle_IRQ_event | | handle_edge_irq | | handle_irq | | __irqentry_text_start | | ret_from_intr | | | | | |--39.78%-- __const_udelay | | | | | | | |--91.89%-- ath5k_hw_register_timeout | | | | ath5k_hw_noise_floor_calibration | | | | ath5k_hw_reset | | | | ath5k_reset | | | | ath5k_config | | | | ieee80211_hw_config | | | | | | | | | |--88.24%-- ieee80211_scan_work | | | | | worker_thread | | | | | kthread | | | | | child_rip | | | | | | | | | --11.76%-- ieee80211_scan_completed | | | | ieee80211_scan_work | | | | worker_thread | | | | kthread | | | | child_rip | | | | | | | --8.11%-- ath5k_hw_noise_floor_calibration | | | ath5k_hw_reset | | | ath5k_reset | | | ath5k_config Note: This does not only affect perf events but also x86-64 stacktraces. They were considered as unreliable once we quit the irq stack frame. Signed-off-by: -
Frederic Weisbecker authored
While dumping a stacktrace, the end of the exception stack won't link the frame pointer to the previous stack. The interrupted stack will then be considered as unreliable and ignored by perf, as the frame pointer is unreliable itself. This happens because we overwrite the frame pointer that links to the interrupted frame with the address of the exception stack. This is done in order to reserve space inside. But rbp has been chosen here only because it is not a scratch register, so that the address of the exception stack remains in rbp after calling do_debug(), we can then release the exception stack space without the need to retrieve its address again. But we can pick another non-scratch register to do that, so that we preserve the link to the interrupted stack frame in the stacktraces. Just randomly choose r12. Every registers are saved just before and restored just after calling do_debug(). And r12 is not used in the middle, which makes it a perfect candidate. Example: perf record -g -a -c 1 -f -e mem:$(tasklist_lock_addr):rw Before: 44.18% [k] _raw_read_lock | | --- |--6.31%-- waitid | |--4.26%-- writev | |--3.63%-- __select | |--3.15%-- __waitpid | | | |--28.57%-- 0x8b52e00000139f | | | |--28.57%-- 0x8b52e0000013c6 | | | |--14.29%-- 0x7fde786dc000 | | | |--14.29%-- 0x62696c2f7273752f | | | --14.29%-- 0x1ea9df800000000 | |--3.00%-- __poll After: 43.94% [k] _raw_read_lock | --- _read_lock | |--60.53%-- send_sigio | __kill_fasync | kill_fasync | evdev_pass_event | evdev_event | input_pass_event | input_handle_event | input_event | synaptics_process_byte | psmouse_handle_byte | psmouse_interrupt | serio_interrupt | i8042_interrupt | handle_IRQ_event | handle_edge_irq | handle_irq | __irqentry_text_start | ret_from_intr | | | |--30.43%-- __select | | | |--17.39%-- 0x454f15 | | | |--13.04%-- __read | | | |--13.04%-- vread_hpet | | | |--13.04%-- _xcb_lock_io | | | --13.04%-- 0x7f630878ce87 Note: it does not only affect perf events but also other stacktraces in x86-64. They were considered as unreliable once we quit the debug stack frame. Signed-off-by: -
Frederic Weisbecker authored
Dumping the callchains from breakpoint events with perf gives strange results: 3.75% perf [kernel] [k] _raw_read_unlock | --- _raw_read_unlock perf_callchain perf_prepare_sample __perf_event_overflow perf_swevent_overflow perf_swevent_add perf_bp_event hw_breakpoint_exceptions_notify notifier_call_chain __atomic_notifier_call_chain atomic_notifier_call_chain notify_die do_debug debug munmap We are infected with all the debug stack. Like the nmi stack, the debug stack is undesired as it is part of the profiling path, not helpful for the user. Ignore it. Signed-off-by:
-
