<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include/linux/ftrace.h, branch v3.9.4</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ftrace: Move ftrace_filter_lseek out of CONFIG_DYNAMIC_FTRACE section</title>
<updated>2013-04-12T21:12:41+00:00</updated>
<author>
<name>Steven Rostedt (Red Hat)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2013-04-12T20:40:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7f49ef69db6bbf756c0abca7e9b65b32e999eec8'/>
<id>7f49ef69db6bbf756c0abca7e9b65b32e999eec8</id>
<content type='text'>
As ftrace_filter_lseek is now used with ftrace_pid_fops, it needs to
be moved out of the #ifdef CONFIG_DYNAMIC_FTRACE section as the
ftrace_pid_fops is defined when DYNAMIC_FTRACE is not.

Cc: stable@vger.kernel.org
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As ftrace_filter_lseek is now used with ftrace_pid_fops, it needs to
be moved out of the #ifdef CONFIG_DYNAMIC_FTRACE section as the
ftrace_pid_fops is defined when DYNAMIC_FTRACE is not.

Cc: stable@vger.kernel.org
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tracing: Fix possible NULL pointer dereferences</title>
<updated>2013-04-12T18:43:34+00:00</updated>
<author>
<name>Namhyung Kim</name>
<email>namhyung.kim@lge.com</email>
</author>
<published>2013-04-11T06:55:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6a76f8c0ab19f215af2a3442870eeb5f0e81998d'/>
<id>6a76f8c0ab19f215af2a3442870eeb5f0e81998d</id>
<content type='text'>
Currently set_ftrace_pid and set_graph_function files use seq_lseek
for their fops.  However seq_open() is called only for FMODE_READ in
the fops-&gt;open() so that if an user tries to seek one of those file
when she open it for writing, it sees NULL seq_file and then panic.

It can be easily reproduced with following command:

  $ cd /sys/kernel/debug/tracing
  $ echo 1234 | sudo tee -a set_ftrace_pid

In this example, GNU coreutils' tee opens the file with fopen(, "a")
and then the fopen() internally calls lseek().

Link: http://lkml.kernel.org/r/1365663302-2170-1-git-send-email-namhyung@kernel.org

Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Namhyung Kim &lt;namhyung.kim@lge.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently set_ftrace_pid and set_graph_function files use seq_lseek
for their fops.  However seq_open() is called only for FMODE_READ in
the fops-&gt;open() so that if an user tries to seek one of those file
when she open it for writing, it sees NULL seq_file and then panic.

It can be easily reproduced with following command:

  $ cd /sys/kernel/debug/tracing
  $ echo 1234 | sudo tee -a set_ftrace_pid

In this example, GNU coreutils' tee opens the file with fopen(, "a")
and then the fopen() internally calls lseek().

Link: http://lkml.kernel.org/r/1365663302-2170-1-git-send-email-namhyung@kernel.org

Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Namhyung Kim &lt;namhyung.kim@lge.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ftrace: Do not call stub functions in control loop</title>
<updated>2013-04-08T16:24:23+00:00</updated>
<author>
<name>Steven Rostedt (Red Hat)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2013-03-27T13:31:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=395b97a3aeff0b8d949ee3e67bf8c11c5ffd6861'/>
<id>395b97a3aeff0b8d949ee3e67bf8c11c5ffd6861</id>
<content type='text'>
The function tracing control loop used by perf spits out a warning
if the called function is not a control function. This is because
the control function references a per cpu allocated data structure
on struct ftrace_ops that is not allocated for other types of
functions.

commit 0a016409e42 "ftrace: Optimize the function tracer list loop"

Had an optimization done to all function tracing loops to optimize
for a single registered ops. Unfortunately, this allows for a slight
race when tracing starts or ends, where the stub function might be
called after the current registered ops is removed. In this case we
get the following dump:

root# perf stat -e ftrace:function sleep 1
[   74.339105] WARNING: at include/linux/ftrace.h:209 ftrace_ops_control_func+0xde/0xf0()
[   74.349522] Hardware name: PRIMERGY RX200 S6
[   74.357149] Modules linked in: sg igb iTCO_wdt ptp pps_core iTCO_vendor_support i7core_edac dca lpc_ich i2c_i801 coretemp edac_core crc32c_intel mfd_core ghash_clmulni_intel dm_multipath acpi_power_meter pcspk
r microcode vhost_net tun macvtap macvlan nfsd kvm_intel kvm auth_rpcgss nfs_acl lockd sunrpc uinput xfs libcrc32c sd_mod crc_t10dif sr_mod cdrom mgag200 i2c_algo_bit drm_kms_helper ttm qla2xxx mptsas ahci drm li
bahci scsi_transport_sas mptscsih libata scsi_transport_fc i2c_core mptbase scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
[   74.446233] Pid: 1377, comm: perf Tainted: G        W    3.9.0-rc1 #1
[   74.453458] Call Trace:
[   74.456233]  [&lt;ffffffff81062e3f&gt;] warn_slowpath_common+0x7f/0xc0
[   74.462997]  [&lt;ffffffff810fbc60&gt;] ? rcu_note_context_switch+0xa0/0xa0
[   74.470272]  [&lt;ffffffff811041a2&gt;] ? __unregister_ftrace_function+0xa2/0x1a0
[   74.478117]  [&lt;ffffffff81062e9a&gt;] warn_slowpath_null+0x1a/0x20
[   74.484681]  [&lt;ffffffff81102ede&gt;] ftrace_ops_control_func+0xde/0xf0
[   74.491760]  [&lt;ffffffff8162f400&gt;] ftrace_call+0x5/0x2f
[   74.497511]  [&lt;ffffffff8162f400&gt;] ? ftrace_call+0x5/0x2f
[   74.503486]  [&lt;ffffffff8162f400&gt;] ? ftrace_call+0x5/0x2f
[   74.509500]  [&lt;ffffffff810fbc65&gt;] ? synchronize_sched+0x5/0x50
[   74.516088]  [&lt;ffffffff816254d5&gt;] ? _cond_resched+0x5/0x40
[   74.522268]  [&lt;ffffffff810fbc65&gt;] ? synchronize_sched+0x5/0x50
[   74.528837]  [&lt;ffffffff811041a2&gt;] ? __unregister_ftrace_function+0xa2/0x1a0
[   74.536696]  [&lt;ffffffff816254d5&gt;] ? _cond_resched+0x5/0x40
[   74.542878]  [&lt;ffffffff8162402d&gt;] ? mutex_lock+0x1d/0x50
[   74.548869]  [&lt;ffffffff81105c67&gt;] unregister_ftrace_function+0x27/0x50
[   74.556243]  [&lt;ffffffff8111eadf&gt;] perf_ftrace_event_register+0x9f/0x140
[   74.563709]  [&lt;ffffffff816254d5&gt;] ? _cond_resched+0x5/0x40
[   74.569887]  [&lt;ffffffff8162402d&gt;] ? mutex_lock+0x1d/0x50
[   74.575898]  [&lt;ffffffff8111e94e&gt;] perf_trace_destroy+0x2e/0x50
[   74.582505]  [&lt;ffffffff81127ba9&gt;] tp_perf_event_destroy+0x9/0x10
[   74.589298]  [&lt;ffffffff811295d0&gt;] free_event+0x70/0x1a0
[   74.595208]  [&lt;ffffffff8112a579&gt;] perf_event_release_kernel+0x69/0xa0
[   74.602460]  [&lt;ffffffff816254d5&gt;] ? _cond_resched+0x5/0x40
[   74.608667]  [&lt;ffffffff8112a640&gt;] put_event+0x90/0xc0
[   74.614373]  [&lt;ffffffff8112a740&gt;] perf_release+0x10/0x20
[   74.620367]  [&lt;ffffffff811a3044&gt;] __fput+0xf4/0x280
[   74.625894]  [&lt;ffffffff811a31de&gt;] ____fput+0xe/0x10
[   74.631387]  [&lt;ffffffff81083697&gt;] task_work_run+0xa7/0xe0
[   74.637452]  [&lt;ffffffff81014981&gt;] do_notify_resume+0x71/0xb0
[   74.643843]  [&lt;ffffffff8162fa92&gt;] int_signal+0x12/0x17

To fix this a new ftrace_ops flag is added that denotes the ftrace_list_end
ftrace_ops stub as just that, a stub. This flag is now checked in the
control loop and the function is not called if the flag is set.

Thanks to Jovi for not just reporting the bug, but also pointing out
where the bug was in the code.

Link: http://lkml.kernel.org/r/514A8855.7090402@redhat.com
Link: http://lkml.kernel.org/r/1364377499-1900-15-git-send-email-jovi.zhangwei@huawei.com

Tested-by: WANG Chao &lt;chaowang@redhat.com&gt;
Reported-by: WANG Chao &lt;chaowang@redhat.com&gt;
Reported-by: zhangwei(Jovi) &lt;jovi.zhangwei@huawei.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The function tracing control loop used by perf spits out a warning
if the called function is not a control function. This is because
the control function references a per cpu allocated data structure
on struct ftrace_ops that is not allocated for other types of
functions.

commit 0a016409e42 "ftrace: Optimize the function tracer list loop"

Had an optimization done to all function tracing loops to optimize
for a single registered ops. Unfortunately, this allows for a slight
race when tracing starts or ends, where the stub function might be
called after the current registered ops is removed. In this case we
get the following dump:

root# perf stat -e ftrace:function sleep 1
[   74.339105] WARNING: at include/linux/ftrace.h:209 ftrace_ops_control_func+0xde/0xf0()
[   74.349522] Hardware name: PRIMERGY RX200 S6
[   74.357149] Modules linked in: sg igb iTCO_wdt ptp pps_core iTCO_vendor_support i7core_edac dca lpc_ich i2c_i801 coretemp edac_core crc32c_intel mfd_core ghash_clmulni_intel dm_multipath acpi_power_meter pcspk
r microcode vhost_net tun macvtap macvlan nfsd kvm_intel kvm auth_rpcgss nfs_acl lockd sunrpc uinput xfs libcrc32c sd_mod crc_t10dif sr_mod cdrom mgag200 i2c_algo_bit drm_kms_helper ttm qla2xxx mptsas ahci drm li
bahci scsi_transport_sas mptscsih libata scsi_transport_fc i2c_core mptbase scsi_tgt dm_mirror dm_region_hash dm_log dm_mod
[   74.446233] Pid: 1377, comm: perf Tainted: G        W    3.9.0-rc1 #1
[   74.453458] Call Trace:
[   74.456233]  [&lt;ffffffff81062e3f&gt;] warn_slowpath_common+0x7f/0xc0
[   74.462997]  [&lt;ffffffff810fbc60&gt;] ? rcu_note_context_switch+0xa0/0xa0
[   74.470272]  [&lt;ffffffff811041a2&gt;] ? __unregister_ftrace_function+0xa2/0x1a0
[   74.478117]  [&lt;ffffffff81062e9a&gt;] warn_slowpath_null+0x1a/0x20
[   74.484681]  [&lt;ffffffff81102ede&gt;] ftrace_ops_control_func+0xde/0xf0
[   74.491760]  [&lt;ffffffff8162f400&gt;] ftrace_call+0x5/0x2f
[   74.497511]  [&lt;ffffffff8162f400&gt;] ? ftrace_call+0x5/0x2f
[   74.503486]  [&lt;ffffffff8162f400&gt;] ? ftrace_call+0x5/0x2f
[   74.509500]  [&lt;ffffffff810fbc65&gt;] ? synchronize_sched+0x5/0x50
[   74.516088]  [&lt;ffffffff816254d5&gt;] ? _cond_resched+0x5/0x40
[   74.522268]  [&lt;ffffffff810fbc65&gt;] ? synchronize_sched+0x5/0x50
[   74.528837]  [&lt;ffffffff811041a2&gt;] ? __unregister_ftrace_function+0xa2/0x1a0
[   74.536696]  [&lt;ffffffff816254d5&gt;] ? _cond_resched+0x5/0x40
[   74.542878]  [&lt;ffffffff8162402d&gt;] ? mutex_lock+0x1d/0x50
[   74.548869]  [&lt;ffffffff81105c67&gt;] unregister_ftrace_function+0x27/0x50
[   74.556243]  [&lt;ffffffff8111eadf&gt;] perf_ftrace_event_register+0x9f/0x140
[   74.563709]  [&lt;ffffffff816254d5&gt;] ? _cond_resched+0x5/0x40
[   74.569887]  [&lt;ffffffff8162402d&gt;] ? mutex_lock+0x1d/0x50
[   74.575898]  [&lt;ffffffff8111e94e&gt;] perf_trace_destroy+0x2e/0x50
[   74.582505]  [&lt;ffffffff81127ba9&gt;] tp_perf_event_destroy+0x9/0x10
[   74.589298]  [&lt;ffffffff811295d0&gt;] free_event+0x70/0x1a0
[   74.595208]  [&lt;ffffffff8112a579&gt;] perf_event_release_kernel+0x69/0xa0
[   74.602460]  [&lt;ffffffff816254d5&gt;] ? _cond_resched+0x5/0x40
[   74.608667]  [&lt;ffffffff8112a640&gt;] put_event+0x90/0xc0
[   74.614373]  [&lt;ffffffff8112a740&gt;] perf_release+0x10/0x20
[   74.620367]  [&lt;ffffffff811a3044&gt;] __fput+0xf4/0x280
[   74.625894]  [&lt;ffffffff811a31de&gt;] ____fput+0xe/0x10
[   74.631387]  [&lt;ffffffff81083697&gt;] task_work_run+0xa7/0xe0
[   74.637452]  [&lt;ffffffff81014981&gt;] do_notify_resume+0x71/0xb0
[   74.643843]  [&lt;ffffffff8162fa92&gt;] int_signal+0x12/0x17

To fix this a new ftrace_ops flag is added that denotes the ftrace_list_end
ftrace_ops stub as just that, a stub. This flag is now checked in the
control loop and the function is not called if the flag is set.

Thanks to Jovi for not just reporting the bug, but also pointing out
where the bug was in the code.

Link: http://lkml.kernel.org/r/514A8855.7090402@redhat.com
Link: http://lkml.kernel.org/r/1364377499-1900-15-git-send-email-jovi.zhangwei@huawei.com

Tested-by: WANG Chao &lt;chaowang@redhat.com&gt;
Reported-by: WANG Chao &lt;chaowang@redhat.com&gt;
Reported-by: zhangwei(Jovi) &lt;jovi.zhangwei@huawei.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ftrace: Move ARCH_SUPPORTS_FTRACE_SAVE_REGS in Kconfig</title>
<updated>2013-01-21T18:22:35+00:00</updated>
<author>
<name>Masami Hiramatsu</name>
<email>masami.hiramatsu.pt@hitachi.com</email>
</author>
<published>2012-09-28T08:15:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=06aeaaeabf69da4a3e86df532425640f51b01cef'/>
<id>06aeaaeabf69da4a3e86df532425640f51b01cef</id>
<content type='text'>
Move SAVE_REGS support flag into Kconfig and rename
it to CONFIG_DYNAMIC_FTRACE_WITH_REGS. This also introduces
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS which indicates
the architecture depending part of ftrace has a code
that saves full registers.
On the other hand, CONFIG_DYNAMIC_FTRACE_WITH_REGS indicates
the code is enabled.

Link: http://lkml.kernel.org/r/20120928081516.3560.72534.stgit@ltc138.sdl.hitachi.co.jp

Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Ananth N Mavinakayanahalli &lt;ananth@in.ibm.com&gt;
Cc: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Signed-off-by: Masami Hiramatsu &lt;masami.hiramatsu.pt@hitachi.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Move SAVE_REGS support flag into Kconfig and rename
it to CONFIG_DYNAMIC_FTRACE_WITH_REGS. This also introduces
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS which indicates
the architecture depending part of ftrace has a code
that saves full registers.
On the other hand, CONFIG_DYNAMIC_FTRACE_WITH_REGS indicates
the code is enabled.

Link: http://lkml.kernel.org/r/20120928081516.3560.72534.stgit@ltc138.sdl.hitachi.co.jp

Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Ananth N Mavinakayanahalli &lt;ananth@in.ibm.com&gt;
Cc: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Signed-off-by: Masami Hiramatsu &lt;masami.hiramatsu.pt@hitachi.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>lseek: the "whence" argument is called "whence"</title>
<updated>2012-12-18T01:15:12+00:00</updated>
<author>
<name>Andrew Morton</name>
<email>akpm@linux-foundation.org</email>
</author>
<published>2012-12-17T23:59:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=965c8e59cfcf845ecde2265a1d1bfee5f011d302'/>
<id>965c8e59cfcf845ecde2265a1d1bfee5f011d302</id>
<content type='text'>
But the kernel decided to call it "origin" instead.  Fix most of the
sites.

Acked-by: Hugh Dickins &lt;hughd@google.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
But the kernel decided to call it "origin" instead.  Fix most of the
sites.

Acked-by: Hugh Dickins &lt;hughd@google.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ftrace: Make ftrace_location() a nop on !DYNAMIC_FTRACE</title>
<updated>2012-07-31T14:29:57+00:00</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2012-06-06T17:45:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4dc936769e8a6382a4cc12375e8a4daa2b829fda'/>
<id>4dc936769e8a6382a4cc12375e8a4daa2b829fda</id>
<content type='text'>
When CONFIG_DYNAMIC_FTRACE is not set, ftrace_location() is not defined.
If a user (like kprobes) references this function, it will break
the compile when CONFIG_DYNAMIC_FTRACE is not set.

Add ftrace_location() as a nop (return 0) when DYNAMIC_FTRACE
is not defined.

Link: http://lkml.kernel.org/r/20120612225426.961092717@goodmis.org

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When CONFIG_DYNAMIC_FTRACE is not set, ftrace_location() is not defined.
If a user (like kprobes) references this function, it will break
the compile when CONFIG_DYNAMIC_FTRACE is not set.

Add ftrace_location() as a nop (return 0) when DYNAMIC_FTRACE
is not defined.

Link: http://lkml.kernel.org/r/20120612225426.961092717@goodmis.org

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ftrace: add ftrace_set_filter_ip() for address based filter</title>
<updated>2012-07-31T14:29:55+00:00</updated>
<author>
<name>Masami Hiramatsu</name>
<email>masami.hiramatsu.pt@hitachi.com</email>
</author>
<published>2012-06-05T10:28:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=647664eaf4033501739ac1f42dd52ce8c9266ccc'/>
<id>647664eaf4033501739ac1f42dd52ce8c9266ccc</id>
<content type='text'>
Add a new filter update interface ftrace_set_filter_ip()
to set ftrace filter by ip address, not only glob pattern.

Link: http://lkml.kernel.org/r/20120605102808.27845.67952.stgit@localhost.localdomain

Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Ananth N Mavinakayanahalli &lt;ananth@in.ibm.com&gt;
Cc: "Frank Ch. Eigler" &lt;fche@redhat.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Signed-off-by: Masami Hiramatsu &lt;masami.hiramatsu.pt@hitachi.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a new filter update interface ftrace_set_filter_ip()
to set ftrace filter by ip address, not only glob pattern.

Link: http://lkml.kernel.org/r/20120605102808.27845.67952.stgit@localhost.localdomain

Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Ananth N Mavinakayanahalli &lt;ananth@in.ibm.com&gt;
Cc: "Frank Ch. Eigler" &lt;fche@redhat.com&gt;
Cc: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Signed-off-by: Masami Hiramatsu &lt;masami.hiramatsu.pt@hitachi.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ftrace: Add selftest to test function trace recursion protection</title>
<updated>2012-07-31T14:29:54+00:00</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2012-07-20T17:08:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ea701f11da44b44907af226fe5a5f57d2f26eeb2'/>
<id>ea701f11da44b44907af226fe5a5f57d2f26eeb2</id>
<content type='text'>
Add selftests to test the function tracing recursion protection actually
does work. It also tests if a ftrace_ops states it will perform its own
protection. Although, even if the ftrace_ops states it will protect itself,
the ftrace infrastructure may still provide protection if the arch does
not support all features or another ftrace_ops is registered.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add selftests to test the function tracing recursion protection actually
does work. It also tests if a ftrace_ops states it will perform its own
protection. Although, even if the ftrace_ops states it will protect itself,
the ftrace infrastructure may still provide protection if the arch does
not support all features or another ftrace_ops is registered.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ftrace: Add default recursion protection for function tracing</title>
<updated>2012-07-31T14:29:52+00:00</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2012-07-20T15:04:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4740974a6844156c14d741b0080b59d275679a23'/>
<id>4740974a6844156c14d741b0080b59d275679a23</id>
<content type='text'>
As more users of the function tracer utility are being added, they do
not always add the necessary recursion protection. To protect from
function recursion due to tracing, if the callback ftrace_ops does not
specifically specify that it protects against recursion (by setting
the FTRACE_OPS_FL_RECURSION_SAFE flag), the list operation will be
called by the mcount trampoline which adds recursion protection.

If the flag is set, then the function will be called directly with no
extra protection.

Note, the list operation is called if more than one function callback
is registered, or if the arch does not support all of the function
tracer features.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As more users of the function tracer utility are being added, they do
not always add the necessary recursion protection. To protect from
function recursion due to tracing, if the callback ftrace_ops does not
specifically specify that it protects against recursion (by setting
the FTRACE_OPS_FL_RECURSION_SAFE flag), the list operation will be
called by the mcount trampoline which adds recursion protection.

If the flag is set, then the function will be called directly with no
extra protection.

Note, the list operation is called if more than one function callback
is registered, or if the arch does not support all of the function
tracer features.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ftrace/x86: Add separate function to save regs</title>
<updated>2012-07-19T17:20:03+00:00</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2012-04-30T20:20:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=08f6fba503111e0336f2b4d6915a4a18f9b60e51'/>
<id>08f6fba503111e0336f2b4d6915a4a18f9b60e51</id>
<content type='text'>
Add a way to have different functions calling different trampolines.
If a ftrace_ops wants regs saved on the return, then have only the
functions with ops registered to save regs. Functions registered by
other ops would not be affected, unless the functions overlap.

If one ftrace_ops registered functions A, B and C and another ops
registered fucntions to save regs on A, and D, then only functions
A and D would be saving regs. Function B and C would work as normal.
Although A is registered by both ops: normal and saves regs; this is fine
as saving the regs is needed to satisfy one of the ops that calls it
but the regs are ignored by the other ops function.

x86_64 implements the full regs saving, and i386 just passes a NULL
for regs to satisfy the ftrace_ops passing. Where an arch must supply
both regs and ftrace_ops parameters, even if regs is just NULL.

It is OK for an arch to pass NULL regs. All function trace users that
require regs passing must add the flag FTRACE_OPS_FL_SAVE_REGS when
registering the ftrace_ops. If the arch does not support saving regs
then the ftrace_ops will fail to register. The flag
FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED may be set that will prevent the
ftrace_ops from failing to register. In this case, the handler may
either check if regs is not NULL or check if ARCH_SUPPORTS_FTRACE_SAVE_REGS.
If the arch supports passing regs it will set this macro and pass regs
for ops that request them. All other archs will just pass NULL.

Link: Link: http://lkml.kernel.org/r/20120711195745.107705970@goodmis.org

Cc: Alexander van Heukelum &lt;heukelum@fastmail.fm&gt;
Reviewed-by: Masami Hiramatsu &lt;masami.hiramatsu.pt@hitachi.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add a way to have different functions calling different trampolines.
If a ftrace_ops wants regs saved on the return, then have only the
functions with ops registered to save regs. Functions registered by
other ops would not be affected, unless the functions overlap.

If one ftrace_ops registered functions A, B and C and another ops
registered fucntions to save regs on A, and D, then only functions
A and D would be saving regs. Function B and C would work as normal.
Although A is registered by both ops: normal and saves regs; this is fine
as saving the regs is needed to satisfy one of the ops that calls it
but the regs are ignored by the other ops function.

x86_64 implements the full regs saving, and i386 just passes a NULL
for regs to satisfy the ftrace_ops passing. Where an arch must supply
both regs and ftrace_ops parameters, even if regs is just NULL.

It is OK for an arch to pass NULL regs. All function trace users that
require regs passing must add the flag FTRACE_OPS_FL_SAVE_REGS when
registering the ftrace_ops. If the arch does not support saving regs
then the ftrace_ops will fail to register. The flag
FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED may be set that will prevent the
ftrace_ops from failing to register. In this case, the handler may
either check if regs is not NULL or check if ARCH_SUPPORTS_FTRACE_SAVE_REGS.
If the arch supports passing regs it will set this macro and pass regs
for ops that request them. All other archs will just pass NULL.

Link: Link: http://lkml.kernel.org/r/20120711195745.107705970@goodmis.org

Cc: Alexander van Heukelum &lt;heukelum@fastmail.fm&gt;
Reviewed-by: Masami Hiramatsu &lt;masami.hiramatsu.pt@hitachi.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
