<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/kernel/trace/trace_sched_wakeup.c, branch linux-5.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-04-10T12:29:43Z</updated>
<entry>
<title>tracing: Fix use-after-free in print_graph_function_flags during tracer switching</title>
<updated>2025-04-10T12:29:43Z</updated>
<author>
<name>Tengda Wu</name>
</author>
<published>2025-03-20T12:21:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=42561fe62c3628ea3bc9623f64f047605e98857f'/>
<id>urn:sha1:42561fe62c3628ea3bc9623f64f047605e98857f</id>
<content type='text'>
commit 7f81f27b1093e4895e87b74143c59c055c3b1906 upstream.

Kairui reported a UAF issue in print_graph_function_flags() during
ftrace stress testing [1]. This issue can be reproduced if puting a
'mdelay(10)' after 'mutex_unlock(&amp;trace_types_lock)' in s_start(),
and executing the following script:

  $ echo function_graph &gt; current_tracer
  $ cat trace &gt; /dev/null &amp;
  $ sleep 5  # Ensure the 'cat' reaches the 'mdelay(10)' point
  $ echo timerlat &gt; current_tracer

The root cause lies in the two calls to print_graph_function_flags
within print_trace_line during each s_show():

  * One through 'iter-&gt;trace-&gt;print_line()';
  * Another through 'event-&gt;funcs-&gt;trace()', which is hidden in
    print_trace_fmt() before print_trace_line returns.

Tracer switching only updates the former, while the latter continues
to use the print_line function of the old tracer, which in the script
above is print_graph_function_flags.

Moreover, when switching from the 'function_graph' tracer to the
'timerlat' tracer, s_start only calls graph_trace_close of the
'function_graph' tracer to free 'iter-&gt;private', but does not set
it to NULL. This provides an opportunity for 'event-&gt;funcs-&gt;trace()'
to use an invalid 'iter-&gt;private'.

To fix this issue, set 'iter-&gt;private' to NULL immediately after
freeing it in graph_trace_close(), ensuring that an invalid pointer
is not passed to other tracers. Additionally, clean up the unnecessary
'iter-&gt;private = NULL' during each 'cat trace' when using wakeup and
irqsoff tracers.

 [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/

Cc: stable@vger.kernel.org
Cc: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Cc: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Cc: Zheng Yejian &lt;zhengyejian1@huawei.com&gt;
Link: https://lore.kernel.org/20250320122137.23635-1-wutengda@huaweicloud.com
Fixes: eecb91b9f98d ("tracing: Fix memleak due to race between current_tracer and trace")
Closes: https://lore.kernel.org/all/CAMgjq7BW79KDSCyp+tZHjShSzHsScSiJxn5ffskp-QzVM06fxw@mail.gmail.com/
Reported-by: Kairui Song &lt;kasong@tencent.com&gt;
Signed-off-by: Tengda Wu &lt;wutengda@huaweicloud.com&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tracing: Fix memleak due to race between current_tracer and trace</title>
<updated>2023-08-30T14:27:23Z</updated>
<author>
<name>Zheng Yejian</name>
</author>
<published>2023-08-17T12:55:39Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=05319d707732c728eb721ac616a50e7978eb499a'/>
<id>urn:sha1:05319d707732c728eb721ac616a50e7978eb499a</id>
<content type='text'>
[ Upstream commit eecb91b9f98d6427d4af5fdb8f108f52572a39e7 ]

Kmemleak report a leak in graph_trace_open():

  unreferenced object 0xffff0040b95f4a00 (size 128):
    comm "cat", pid 204981, jiffies 4301155872 (age 99771.964s)
    hex dump (first 32 bytes):
      e0 05 e7 b4 ab 7d 00 00 0b 00 01 00 00 00 00 00 .....}..........
      f4 00 01 10 00 a0 ff ff 00 00 00 00 65 00 10 00 ............e...
    backtrace:
      [&lt;000000005db27c8b&gt;] kmem_cache_alloc_trace+0x348/0x5f0
      [&lt;000000007df90faa&gt;] graph_trace_open+0xb0/0x344
      [&lt;00000000737524cd&gt;] __tracing_open+0x450/0xb10
      [&lt;0000000098043327&gt;] tracing_open+0x1a0/0x2a0
      [&lt;00000000291c3876&gt;] do_dentry_open+0x3c0/0xdc0
      [&lt;000000004015bcd6&gt;] vfs_open+0x98/0xd0
      [&lt;000000002b5f60c9&gt;] do_open+0x520/0x8d0
      [&lt;00000000376c7820&gt;] path_openat+0x1c0/0x3e0
      [&lt;00000000336a54b5&gt;] do_filp_open+0x14c/0x324
      [&lt;000000002802df13&gt;] do_sys_openat2+0x2c4/0x530
      [&lt;0000000094eea458&gt;] __arm64_sys_openat+0x130/0x1c4
      [&lt;00000000a71d7881&gt;] el0_svc_common.constprop.0+0xfc/0x394
      [&lt;00000000313647bf&gt;] do_el0_svc+0xac/0xec
      [&lt;000000002ef1c651&gt;] el0_svc+0x20/0x30
      [&lt;000000002fd4692a&gt;] el0_sync_handler+0xb0/0xb4
      [&lt;000000000c309c35&gt;] el0_sync+0x160/0x180

The root cause is descripted as follows:

  __tracing_open() {  // 1. File 'trace' is being opened;
    ...
    *iter-&gt;trace = *tr-&gt;current_trace;  // 2. Tracer 'function_graph' is
                                        //    currently set;
    ...
    iter-&gt;trace-&gt;open(iter);  // 3. Call graph_trace_open() here,
                              //    and memory are allocated in it;
    ...
  }

  s_start() {  // 4. The opened file is being read;
    ...
    *iter-&gt;trace = *tr-&gt;current_trace;  // 5. If tracer is switched to
                                        //    'nop' or others, then memory
                                        //    in step 3 are leaked!!!
    ...
  }

To fix it, in s_start(), close tracer before switching then reopen the
new tracer after switching. And some tracers like 'wakeup' may not update
'iter-&gt;private' in some cases when reopen, then it should be cleared
to avoid being mistakenly closed again.

Link: https://lore.kernel.org/linux-trace-kernel/20230817125539.1646321-1-zhengyejian1@huawei.com

Fixes: d7350c3f4569 ("tracing/core: make the read callbacks reentrants")
Signed-off-by: Zheng Yejian &lt;zhengyejian1@huawei.com&gt;
Signed-off-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>kernel/trace: Fix do not unregister tracepoints when register sched_migrate_task fail</title>
<updated>2020-01-14T19:08:22Z</updated>
<author>
<name>Kaitao Cheng</name>
</author>
<published>2019-12-31T13:35:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=654eced27a13c5b45af9ea9ca7e4626bb050eb68'/>
<id>urn:sha1:654eced27a13c5b45af9ea9ca7e4626bb050eb68</id>
<content type='text'>
commit 50f9ad607ea891a9308e67b81f774c71736d1098 upstream.

In the function, if register_trace_sched_migrate_task() returns error,
sched_switch/sched_wakeup_new/sched_wakeup won't unregister. That is
why fail_deprobe_sched_switch was added.

Link: http://lkml.kernel.org/r/20191231133530.2794-1-pilgrimtao@gmail.com

Cc: stable@vger.kernel.org
Fixes: 478142c39c8c2 ("tracing: do not grab lock in wakeup latency function tracing")
Signed-off-by: Kaitao Cheng &lt;pilgrimtao@gmail.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>sched/core: Convert get_task_struct() to return the task</title>
<updated>2019-07-25T13:51:54Z</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
</author>
<published>2019-07-04T22:13:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7b3c92b85a65c2db1f542265bc98e1f9e3056eba'/>
<id>urn:sha1:7b3c92b85a65c2db1f542265bc98e1f9e3056eba</id>
<content type='text'>
Returning the pointer that was passed in allows us to write
slightly more idiomatic code.  Convert a few users.

Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lkml.kernel.org/r/20190704221323.24290-1-willy@infradead.org
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>tracing: Add conditional snapshot</title>
<updated>2019-02-20T18:51:06Z</updated>
<author>
<name>Tom Zanussi</name>
</author>
<published>2019-02-13T23:42:45Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a35873a0993b4d38b40871f10fa4356c088c7140'/>
<id>urn:sha1:a35873a0993b4d38b40871f10fa4356c088c7140</id>
<content type='text'>
Currently, tracing snapshots are context-free - they capture the ring
buffer contents at the time the tracing_snapshot() function was
invoked, and nothing else.  Additionally, they're always taken
unconditionally - the calling code can decide whether or not to take a
snapshot, but the data used to make that decision is kept separately
from the snapshot itself.

This change adds the ability to associate with each trace instance
some user data, along with an 'update' function that can use that data
to determine whether or not to actually take a snapshot.  The update
function can then update that data along with any other state (as part
of the data presumably), if warranted.

Because snapshots are 'global' per-instance, only one user can enable
and use a conditional snapshot for any given trace instance.  To
enable a conditional snapshot (see details in the function and data
structure comments), the user calls tracing_snapshot_cond_enable().
Similarly, to disable a conditional snapshot and free it up for other
users, tracing_snapshot_cond_disable() should be called.

To actually initiate a conditional snapshot, tracing_snapshot_cond()
should be called.  tracing_snapshot_cond() will invoke the update()
callback, allowing the user to decide whether or not to actually take
the snapshot and update the user-defined data associated with the
snapshot.  If the callback returns 'true', tracing_snapshot_cond()
will then actually take the snapshot and return.

This scheme allows for flexibility in snapshot implementations - for
example, by implementing slightly different update() callbacks,
snapshots can be taken in situations where the user is only interested
in taking a snapshot when a new maximum in hit versus when a value
changes in any way at all.  Future patches will demonstrate both
cases.

Link: http://lkml.kernel.org/r/1bea07828d5fd6864a585f83b1eed47ce097eb45.1550100284.git.tom.zanussi@linux.intel.com

Signed-off-by: Tom Zanussi &lt;tom.zanussi@linux.intel.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracing: Show stacktrace for wakeup tracers</title>
<updated>2019-02-06T16:56:19Z</updated>
<author>
<name>Changbin Du</name>
</author>
<published>2019-01-16T16:02:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f52d569f3d929d9530d75976baa191d2d50fc51b'/>
<id>urn:sha1:f52d569f3d929d9530d75976baa191d2d50fc51b</id>
<content type='text'>
This align the behavior of wakeup tracers with irqsoff latency tracer
that we record stacktrace at the beginning and end of waking up. The
stacktrace shows us what is happening in the kernel.

Link: http://lkml.kernel.org/r/20190116160249.7554-1-changbin.du@gmail.com

Signed-off-by: Changbin Du &lt;changbin.du@gmail.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracing: Show more info for funcgraph wakeup tracers</title>
<updated>2019-02-06T16:56:19Z</updated>
<author>
<name>Changbin Du</name>
</author>
<published>2019-01-01T15:46:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=97f0a3bcdf34f66c2017bad51445eafef1224870'/>
<id>urn:sha1:97f0a3bcdf34f66c2017bad51445eafef1224870</id>
<content type='text'>
Add these info fields to funcgraph wakeup tracers:
  o Show CPU info since the waker could be on a different CPU.
  o Show function duration and overhead.
  o Show IRQ markers.

Link: http://lkml.kernel.org/r/20190101154614.8887-3-changbin.du@gmail.com

Signed-off-by: Changbin Du &lt;changbin.du@gmail.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>function_graph: Support displaying relative timestamp</title>
<updated>2019-02-06T16:56:18Z</updated>
<author>
<name>Changbin Du</name>
</author>
<published>2019-01-01T15:46:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9acd8de69d107537a68d010c9149fa9d9aba91f4'/>
<id>urn:sha1:9acd8de69d107537a68d010c9149fa9d9aba91f4</id>
<content type='text'>
When function_graph is used for latency tracers, relative timestamp
is more straightforward than absolute timestamp as function trace
does. This change adds relative timestamp support to function_graph
and applies to latency tracers (wakeup and irqsoff).

Instead of:

 # tracer: irqsoff
 #
 # irqsoff latency trace v1.1.5 on 5.0.0-rc1-test
 # --------------------------------------------------------------------
 # latency: 521 us, #1125/1125, CPU#2 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:8)
 #    -----------------
 #    | task: swapper/2-0 (uid:0 nice:0 policy:0 rt_prio:0)
 #    -----------------
 #  =&gt; started at: __schedule
 #  =&gt; ended at:   _raw_spin_unlock_irq
 #
 #
 #                                       _-----=&gt; irqs-off
 #                                      / _----=&gt; need-resched
 #                                     | / _---=&gt; hardirq/softirq
 #                                     || / _--=&gt; preempt-depth
 #                                     ||| /
 #     TIME        CPU  TASK/PID       ||||  DURATION                  FUNCTION CALLS
 #      |          |     |    |        ||||   |   |                     |   |   |   |
   124.974306 |   2)  systemd-693   |  d..1  0.000 us    |  __schedule();
   124.974307 |   2)  systemd-693   |  d..1              |    rcu_note_context_switch() {
   124.974308 |   2)  systemd-693   |  d..1  0.487 us    |      rcu_preempt_deferred_qs();
   124.974309 |   2)  systemd-693   |  d..1  0.451 us    |      rcu_qs();
   124.974310 |   2)  systemd-693   |  d..1  2.301 us    |    }
[..]
   124.974826 |   2)    &lt;idle&gt;-0    |  d..2              |  finish_task_switch() {
   124.974826 |   2)    &lt;idle&gt;-0    |  d..2              |    _raw_spin_unlock_irq() {
   124.974827 |   2)    &lt;idle&gt;-0    |  d..2  0.000 us    |  _raw_spin_unlock_irq();
   124.974828 |   2)    &lt;idle&gt;-0    |  d..2  0.000 us    |  tracer_hardirqs_on();
   &lt;idle&gt;-0       2d..2  552us : &lt;stack trace&gt;
  =&gt; __schedule
  =&gt; schedule_idle
  =&gt; do_idle
  =&gt; cpu_startup_entry
  =&gt; start_secondary
  =&gt; secondary_startup_64

Show:

 # tracer: irqsoff
 #
 # irqsoff latency trace v1.1.5 on 5.0.0-rc1-test+
 # --------------------------------------------------------------------
 # latency: 511 us, #1053/1053, CPU#7 | (M:preempt VP:0, KP:0, SP:0 HP:0 #P:8)
 #    -----------------
 #    | task: swapper/7-0 (uid:0 nice:0 policy:0 rt_prio:0)
 #    -----------------
 #  =&gt; started at: __schedule
 #  =&gt; ended at:   _raw_spin_unlock_irq
 #
 #
 #                                       _-----=&gt; irqs-off
 #                                      / _----=&gt; need-resched
 #                                     | / _---=&gt; hardirq/softirq
 #                                     || / _--=&gt; preempt-depth
 #                                     ||| /
 #   REL TIME      CPU  TASK/PID       ||||  DURATION                  FUNCTION CALLS
 #      |          |     |    |        ||||   |   |                     |   |   |   |
         0 us |   7)   sshd-1704    |  d..1  0.000 us    |  __schedule();
         1 us |   7)   sshd-1704    |  d..1              |    rcu_note_context_switch() {
         1 us |   7)   sshd-1704    |  d..1  0.611 us    |      rcu_preempt_deferred_qs();
         2 us |   7)   sshd-1704    |  d..1  0.484 us    |      rcu_qs();
         3 us |   7)   sshd-1704    |  d..1  2.599 us    |    }
[..]
       509 us |   7)    &lt;idle&gt;-0    |  d..2              |  finish_task_switch() {
       510 us |   7)    &lt;idle&gt;-0    |  d..2              |    _raw_spin_unlock_irq() {
       510 us |   7)    &lt;idle&gt;-0    |  d..2  0.000 us    |  _raw_spin_unlock_irq();
       512 us |   7)    &lt;idle&gt;-0    |  d..2  0.000 us    |  tracer_hardirqs_on();
   &lt;idle&gt;-0       7d..2  543us : &lt;stack trace&gt;
  =&gt; __schedule
  =&gt; schedule_idle
  =&gt; do_idle
  =&gt; cpu_startup_entry
  =&gt; start_secondary
  =&gt; secondary_startup_64

Link: http://lkml.kernel.org/r/20190101154614.8887-2-changbin.du@gmail.com

Signed-off-by: Changbin Du &lt;changbin.du@gmail.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>fgraph: Add new fgraph_ops structure to enable function graph hooks</title>
<updated>2018-12-09T01:54:07Z</updated>
<author>
<name>Steven Rostedt (VMware)</name>
</author>
<published>2018-11-15T19:06:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=688f7089d8851b1a81106f0c0b9b29181b2f2dc8'/>
<id>urn:sha1:688f7089d8851b1a81106f0c0b9b29181b2f2dc8</id>
<content type='text'>
Currently the registering of function graph is to pass in a entry and return
function. We need to have a way to associate those functions together where
the entry can determine to run the return hook. Having a structure that
contains both functions will facilitate the process of converting the code
to be able to do such.

This is similar to the way function hooks are enabled (it passes in
ftrace_ops). Instead of passing in the functions to use, a single structure
is passed in to the registering function.

The unregister function is now passed in the fgraph_ops handle. When we
allow more than one callback to the function graph hooks, this will let the
system know which one to remove.

Reviewed-by: Joel Fernandes (Google) &lt;joel@joelfernandes.org&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracing: Rearrange functions in trace_sched_wakeup.c</title>
<updated>2018-12-09T01:54:07Z</updated>
<author>
<name>Steven Rostedt (VMware)</name>
</author>
<published>2018-11-28T15:26:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=317e04ca905ac6c4b33cb879e9a107c412125f14'/>
<id>urn:sha1:317e04ca905ac6c4b33cb879e9a107c412125f14</id>
<content type='text'>
Rearrange the functions in trace_sched_wakeup.c so that there are fewer
 #ifdef CONFIG_FUNCTION_TRACER and #ifdef CONFIG_FUNCTION_GRAPH_TRACER,
instead of having the #ifdefs spread all over.

No functional change is made.

Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
</feed>
