- 24 Jul, 2014 2 commits
-
-
Steven Rostedt (Red Hat) authored
After adding all the records to the tramp_hash, add a check that makes sure that the number of records added matches the number of records expected to match and do a WARN_ON and disable ftrace if they do not match. Signed-off-by:Steven Rostedt <rostedt@goodmis.org>
-
Steven Rostedt (Red Hat) authored
In the loop of ftrace_save_ops_tramp_hash(), it adds all the recs to the ops hash if the rec has only one callback attached and the ops is connected to the rec. It gives a nasty warning and shuts down ftrace if the rec doesn't have a trampoline set for it. But this can happen with the following scenario: # cd /sys/kernel/debug/tracing # echo schedule do_IRQ > set_ftrace_filter # mkdir instances/foo # echo schedule > instances/foo/set_ftrace_filter # echo function_graph > current_function # echo function > instances/foo/current_function # echo nop > instances/foo/current_function The above would then trigger the following warning and disable ftrace: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3145 at kernel/trace/ftrace.c:2212 ftrace_run_update_code+0xe4/0x15b() Modules linked in: ipt_MASQUERADE sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ip [...] CPU: 1 PID: 3145 Comm: bash Not tainted 3.16.0-rc3-test+ #136 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 0000000000000000 ffffffff81808a88 ffffffff81502130 0000000000000000 ffffffff81040ca1 ffff880077c08000 ffffffff810bd286 0000000000000001 ffffffff81a56830 ffff88007a041be0 ffff88007a872d60 00000000000001be Call Trace: [<ffffffff81502130>] ? dump_stack+0x4a/0x75 [<ffffffff81040ca1>] ? warn_slowpath_common+0x7e/0x97 [<ffffffff810bd286>] ? ftrace_run_update_code+0xe4/0x15b [<ffffffff810bd286>] ? ftrace_run_update_code+0xe4/0x15b [<ffffffff810bda1a>] ? ftrace_shutdown+0x11c/0x16b [<ffffffff810bda87>] ? unregister_ftrace_function+0x1e/0x38 [<ffffffff810cc7e1>] ? function_trace_reset+0x1a/0x28 [<ffffffff810c924f>] ? tracing_set_tracer+0xc1/0x276 [<ffffffff810c9477>] ? tracing_set_trace_write+0x73/0x91 [<ffffffff81132383>] ? __sb_start_write+0x9a/0xcc [<ffffffff8120478f>] ? security_file_permission+0x1b/0x31 [<ffffffff81130e49>] ? vfs_write+0xac/0x11c [<ffffffff8113115d>] ? SyS_write+0x60/0x8e [<ffffffff81508112>] ? system_call_fastpath+0x16/0x1b ---[ end trace 938c4415cbc7dc96 ]--- ------------[ cut here ]------------ Link: http://lkml.kernel.org/r/20140723120805.GB21376@redhat.comReported-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
-
- 23 Jul, 2014 2 commits
-
-
Steven Rostedt (Red Hat) authored
There's a helper function to get a ring buffer page size (the number of bytes of data recorded on the page), called rb_page_size(). Use that instead of open coding it. Signed-off-by: -
Steven Rostedt (Red Hat) authored
Having two fields within the same struct that is off by one character can be confusing and error prone. Rename the counter "trampolines" to "nr_trampolines" to explicitly show it is a counter and not to be confused by the "trampoline" field. Suggested-by:
-
- 19 Jul, 2014 1 commit
-
-
Steven Rostedt (Red Hat) authored
Local functions should be static. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
- 18 Jul, 2014 25 commits
-
-
Wang Nan authored
Do not waste time copying the old hash if the hash is going to be reset. Just allocate a new hash and free the old one, as that is the same result as copying te old one and then resetting it. Link: http://lkml.kernel.org/p/1405384820-48837-1-git-send-email-wangnan0@huawei.comSigned-off-by:
Wang Nan <wangnan0@huawei.com> [ SDR: Removed unused ftrace_filter_reset() function ] Signed-off-by:
-
Stanislav Fomichev authored
Currently, tracing_thresh works only if we specify it before selecting function_graph tracer. If we do the opposite, tracing_thresh will change it's value, but it will not be applied. To fix it, we add update_thresh callback which is called whenever tracing_thresh is updated and for function_graph tracer we register handler which reinitializes tracer depending on tracing_thresh. Link: http://lkml.kernel.org/p/20140718111727.GA3206@stfomichev-desktop.yandex.netSigned-off-by:
Stanislav Fomichev <stfomichev@yandex-team.ru> Signed-off-by:
-
Corey Minyard authored
The code for resizing the trace ring buffers has to run the per-cpu resize on the CPU itself. The code was using preempt_off() and running the code for the current CPU directly, otherwise calling schedule_work_on(). At least on RT this could result in the following: |BUG: sleeping function called from invalid context at kernel/rtmutex.c:673 |in_atomic(): 1, irqs_disabled(): 0, pid: 607, name: bash |3 locks held by bash/607: |CPU: 0 PID: 607 Comm: bash Not tainted 3.12.15-rt25+ #124 |(rt_spin_lock+0x28/0x68) |(free_hot_cold_page+0x84/0x3b8) |(free_buffer_page+0x14/0x20) |(rb_update_pages+0x280/0x338) |(ring_buffer_resize+0x32c/0x3dc) |(free_snapshot+0x18/0x38) |(tracing_set_tracer+0x27c/0x2ac) probably via |cd /sys/kernel/debug/tracing/ |echo 1 > events/enable ; sleep 2 |echo 1024 > buffer_size_kb If we just always use schedule_work_on(), there's no need for the preempt_off(). So do that. Link: http://lkml.kernel.org/p/1405537633-31518-1-git-send-email-cminyard@mvista.comReported-by:
Stanislav Meduna <stano@meduna.org> Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
All users of function_trace_stop and HAVE_FUNCTION_TRACE_MCOUNT_TEST have been removed. We can safely remove them from the kernel. Reviewed-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by:
-
Heiko Carstens authored
Remove check of obsolete variable function_trace_stop as requested by Steven Rostedt. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
Nothing sets function_trace_stop to disable function tracing anymore. Remove the check for it in the arch code. arm64 was broken anyway, as it had an ifdef testing CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST which is only set if the arch supports the code (which it obviously did not), and it was testing a non existent ftrace_trace_stop instead of function_trace_stop. Link: http://lkml.kernel.org/r/20140627124421.GP26276@arm.com Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
Nothing sets function_trace_stop to disable function tracing anymore. Remove the check for it in the arch code. Link: http://lkml.kernel.org/r/3144266.ziutPk5CNZ@vapierAcked-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
Nothing sets function_trace_stop to disable function tracing anymore. Remove the check for it in the arch code. Acked-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
Nothing sets function_trace_stop to disable function tracing anymore. Remove the check for it in the arch code. Link: http://lkml.kernel.org/r/53C8D82B.4030204@monstr.euTested-by:
Michal Simek <monstr@monstr.eu> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
Nothing sets function_trace_stop to disable function tracing anymore. Remove the check for it in the arch code. Cc: Ralf Baechle <ralf@linux-mips.org> Tested-by:
-
Steven Rostedt (Red Hat) authored
Nothing sets function_trace_stop to disable function tracing anymore. Remove the check for it in the arch code. Link: http://lkml.kernel.org/r/53B08317.7010501@gmx.de Cc: Kyle McMartin <kyle@mcmartin.ca> Acked-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
Nothing sets function_trace_stop to disable function tracing anymore. Remove the check for it in the arch code. [ Please test this on your arch ] Cc: Matt Fleming <matt@console-pimps.org> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: -
Steven Rostedt (Red Hat) authored
Nothing sets function_trace_stop to disable function tracing anymore. Remove the check for it in the arch code. Link: http://lkml.kernel.org/r/20140703.211820.1674895115102216877.davem@davemloft.net Cc: David S. Miller <davem@davemloft.net> OKed-to-go-through-tracing-tree-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
Nothing sets function_trace_stop to disable function tracing anymore. Remove the check for it in the arch code. Cc: Chris Metcalf <cmetcalf@tilera.com> Acked-by: Zhigang Lu<zlu@tilera.com> Signed-off-by: -
Steven Rostedt (Red Hat) authored
Nothing sets function_trace_stop to disable function tracing anymore. Remove the check for it in the arch code. Link: http://lkml.kernel.org/r/53C54D32.6000000@zytor.comAcked-by:
H. Peter Anvin <hpa@linux.intel.com> Reviewed-by:
-
Steven Rostedt (Red Hat) authored
function_trace_stop is no longer used to disable function tracing. This means that archs are no longer limited if it does not support checking this variable in the mcount trampoline. No need to use the list_func for archs that do not support this obsolete method. Acked-by:
-
Steven Rostedt (Red Hat) authored
function_trace_stop is no longer used to stop function tracing. Remove the check from __ftrace_ops_list_func(). Also, call FTRACE_WARN_ON() instead of setting function_trace_stop if a ops has no func to call. Reviewed-by:
-
Steven Rostedt (Red Hat) authored
When function tracing is being updated function_trace_stop is set to keep from tracing the updates. This was fine when function tracing was done from stop machine. But it is no longer done that way and this can cause real tracing to be missed. Remove it. Reviewed-by:
-
Steven Rostedt (Red Hat) authored
There are no more kernel users of ftrace_stop() and ftrace_start(). Remove them. Reviewed-by:
-
Steven Rostedt (Red Hat) authored
All archs now use ftrace_graph_is_dead() to stop function graph tracing. Remove the usage of ftrace_stop() as that is no longer needed. Cc: Frederic Weisbecker <fweisbec@gmail.com> Reviewed-by:
-
Steven Rostedt (Red Hat) authored
ftrace_stop() is going away as it disables parts of function tracing that affects users that should not be affected. But ftrace_graph_stop() is built on ftrace_stop(). Here's another example of killing all of function tracing because something went wrong with function graph tracing. Instead of disabling all users of function tracing on function graph error, disable only function graph tracing. To do this, the arch code must call ftrace_graph_is_dead() before it implements function graph. Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by: -
Steven Rostedt (Red Hat) authored
ftrace_stop() is going away as it disables parts of function tracing that affects users that should not be affected. But ftrace_graph_stop() is built on ftrace_stop(). Here's another example of killing all of function tracing because something went wrong with function graph tracing. Instead of disabling all users of function tracing on function graph error, disable only function graph tracing. To do this, the arch code must call ftrace_graph_is_dead() before it implements function graph. Cc: Anton Blanchard <anton@samba.org> Acked-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
ftrace_stop() is going away as it disables parts of function tracing that affects users that should not be affected. But ftrace_graph_stop() is built on ftrace_stop(). Here's another example of killing all of function tracing because something went wrong with function graph tracing. Instead of disabling all users of function tracing on function graph error, disable only function graph tracing. To do this, the arch code must call ftrace_graph_is_dead() before it implements function graph. Link: http://lkml.kernel.org/r/53B08317.7010501@gmx.de Cc: Kyle McMartin <kyle@mcmartin.ca> Acked-by:
-
Steven Rostedt (Red Hat) authored
ftrace_stop() is going away as it disables parts of function tracing that affects users that should not be affected. But ftrace_graph_stop() is built on ftrace_stop(). Here's another example of killing all of function tracing because something went wrong with function graph tracing. Instead of disabling all users of function tracing on function graph error, disable only function graph tracing. To do this, the arch code must call ftrace_graph_is_dead() before it implements function graph. Cc: Ralf Baechle <ralf@linux-mips.org> Tested-by:
-
Steven Rostedt (Red Hat) authored
ftrace_stop() is going away as it disables parts of function tracing that affects users that should not be affected. But ftrace_graph_stop() is built on ftrace_stop(). Here's another example of killing all of function tracing because something went wrong with function graph tracing. Instead of disabling all users of function tracing on function graph error, disable only function graph tracing. To do this, the arch code must call ftrace_graph_is_dead() before it implements function graph. Link: http://lkml.kernel.org/r/53C8D874.9090601@monstr.euTested-by:
-
- 17 Jul, 2014 5 commits
-
-
Steven Rostedt (Red Hat) authored
ftrace_stop() is going away as it disables parts of function tracing that affects users that should not be affected. But ftrace_graph_stop() is built on ftrace_stop(). Here's another example of killing all of function tracing because something went wrong with function graph tracing. Instead of disabling all users of function tracing on function graph error, disable only function graph tracing. To do this, the arch code must call ftrace_graph_is_dead() before it implements function graph. Link: http://lkml.kernel.org/r/53C54D18.3020602@zytor.comAcked-by:
-
Steven Rostedt (Red Hat) authored
ftrace_stop() is going away as it disables parts of function tracing that affects users that should not be affected. But ftrace_graph_stop() is built on ftrace_stop(). Here's another example of killing all of function tracing because something went wrong with function graph tracing. Instead of disabling all users of function tracing on function graph error, disable only function graph tracing. A new function is created called ftrace_graph_is_dead(). This is called in strategic paths to prevent function graph from doing more harm and allowing at least a warning to be printed before the system crashes. NOTE: ftrace_stop() is still used until all the archs are converted over to use ftrace_graph_is_dead(). After that, ftrace_stop() will be removed. Reviewed-by:
-
Steven Rostedt (Red Hat) authored
ftrace_stop() and ftrace_start() were added to the suspend and hibernate process because there was some function within the work flow that caused the system to reboot if it was traced. This function has recently been found (restore_processor_state()). Now there's no reason to disable function tracing while we are going into suspend or hibernate, which means that being able to trace this will help tremendously in debugging any issues with suspend or hibernate. This also means that the ftrace_stop/start() functions can be removed and simplify the function tracing code a bit. Link: http://lkml.kernel.org/r/1518201.VD9cU33jRU@vostro.rjw.lanAcked-by:
"Rafael J. Wysocki" <rjw@rjwysocki.net> Reviewed-by:
-
Steven Rostedt (Red Hat) authored
ftrace_stop() is used to stop function tracing during suspend and resume which removes a lot of possible debugging opportunities with tracing. The reason was that some function in the resume path was causing a triple fault if it were to be traced. The issue I found was that doing something as simple as calling smp_processor_id() would reboot the box! When function tracing was first created I didn't have a good way to figure out what function was having issues, or it looked to be multiple ones. To fix it, we just created a big hammer approach to the problem which was to add a flag in the mcount trampoline that could be checked and not call the traced functions. Lately I developed better ways to find problem functions and I can bisect down to see what function is causing the issue. I removed the flag that stopped tracing and proceeded to find the problem function and it ended up being restore_processor_state(). This function makes sense as when the CPU comes back online from a suspend it calls this function to set up registers, amongst them the GS register, which stores things such as what CPU the processor is (if you call smp_processor_id() without this set up properly, it would fault). By making restore_processor_state() notrace, the system can suspend and resume without the need of the big hammer tracing to stop. Link: http://lkml.kernel.org/r/3577662.BSnUZfboWb@vostro.rjw.lanAcked-by:
-
Steven Rostedt (Red Hat) authored
The function graph trampoline is called from the function trampoline and both do a save and restore of registers. The save of registers done by the function trampoline when only the function graph tracer is running is a waste of CPU cycles. As the function graph tracer trampoline in x86 is dependent from the function trampoline, we can call it directly when a function is only being traced by the function graph trampoline. Acked-by:
-
- 16 Jul, 2014 1 commit
-
-
Steven Rostedt (Red Hat) authored
Currently if an arch supports function graph tracing, the core code will just assign the function graph trampoline to the function graph addr that gets called. But as the old method for function graph tracing always calls the function trampoline first and that calls the function graph trampoline, some archs may have the function graph trampoline dependent on operations that were done in the function trampoline. This causes function graph tracer to break on those archs. Instead of having the default be to set the function graph ftrace_ops to the function graph trampoline, have it instead just set it to zero which will keep it from jumping to a trampoline that is not set up to be jumped directly too. Link: http://lkml.kernel.org/r/53BED155.9040607@nvidia.comReported-by:
Tuomas Tynkkynen <ttynkkynen@nvidia.com> Tested-by:
-
- 09 Jul, 2014 1 commit
-
-
Steven Rostedt (Red Hat) authored
Needed 099ed151 "tracing: Remove ftrace_stop/start() from reading the trace file" for the removal of ftrace_start/stop().
-
- 01 Jul, 2014 3 commits
-
-
Steven Rostedt (Red Hat) authored
Disabling reading and writing to the trace file should not be able to disable all function tracing callbacks. There's other users today (like kprobes and perf). Reading a trace file should not stop those from happening. Cc: stable@vger.kernel.org # 3.0+ Reviewed-by:
-
Namhyung Kim authored
It was missing the description of set_graph_notrace file. Add it. Link: http://lkml.kernel.org/p/1402590233-22321-5-git-send-email-namhyung@kernel.orgSigned-off-by:
Namhyung Kim <namhyung@kernel.org> Signed-off-by:
-
Namhyung Kim authored
When there's no entry in set_ftrace_notrace, it'll print nothing, but it's better to print something like below like set_graph_notrace does: #### no functions disabled #### Link: http://lkml.kernel.org/p/1402644246-4649-1-git-send-email-namhyung@kernel.orgReported-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Signed-off-by:
-
