- 18 Jul, 2014 23 commits
-
-
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 <rostedt@goodmis.org>
-
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 10 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:
-
Namhyung Kim authored
When there's no entry in set_graph_notrace, it'll print below message #### all functions enabled #### While this is technically correct, it's better to print like below: #### no functions disabled #### Link: http://lkml.kernel.org/p/1402590233-22321-3-git-send-email-namhyung@kernel.orgReported-by:
-
Namhyung Kim authored
The ftrace_graph_notrace option is for specifying notrace filter for function graph tracer at boot time. It can be altered after boot using set_graph_notrace file on the debugfs. Link: http://lkml.kernel.org/p/1402590233-22321-2-git-send-email-namhyung@kernel.orgSigned-off-by:
-
Fabian Frederick authored
Convert pr_warning to standard pr_warn Define pr_fmt(fmt) fmt to avoid any future default fmt definition Link: http://lkml.kernel.org/p/1402141388-21144-1-git-send-email-fabf@skynet.beSigned-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
-
Namhyung Kim authored
When a filter file is open for writing and O_TRUNC is set, there's no need to copy and free the filter entries. Link: http://lkml.kernel.org/p/1402474014-28655-2-git-send-email-namhyung@kernel.orgSigned-off-by:
-
Namhyung Kim authored
As struct ftrace_page is managed in a single linked list, it should free from the start page. Link: http://lkml.kernel.org/p/1402474014-28655-1-git-send-email-namhyung@kernel.orgSigned-off-by:
-
Namhyung Kim authored
It seems like it's a leftover from commit 4104d326 ("ftrace: Remove global function list and call function directly"). As it isn't updated at all, checking its value is meaningless. Let's get rid of it. Link: http://lkml.kernel.org/p/1402584972-17824-1-git-send-email-namhyung@kernel.orgSigned-off-by:
-
Steven Rostedt (Red Hat) authored
There's several locations in the kernel that open code the calculation of the next location in the trace_seq buffer. This is usually done with p->buffer + p->len Instead of having this open coded, supply a helper function in the header to do it for them. This function is called trace_seq_buffer_ptr(). Link: http://lkml.kernel.org/p/20140626220129.452783019@goodmis.orgAcked-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
