<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/kernel/trace, branch v5.5</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v5.5</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v5.5'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2020-01-22T12:09:20Z</updated>
<entry>
<title>tracing/uprobe: Fix to make trace_uprobe_filter alignment safe</title>
<updated>2020-01-22T12:09:20Z</updated>
<author>
<name>Masami Hiramatsu</name>
<email>mhiramat@kernel.org</email>
</author>
<published>2020-01-22T03:23:25Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b61387cb732cf283d318b2165c44913525fe545f'/>
<id>urn:sha1:b61387cb732cf283d318b2165c44913525fe545f</id>
<content type='text'>
Commit 99c9a923e97a ("tracing/uprobe: Fix double perf_event
linking on multiprobe uprobe") moved trace_uprobe_filter on
trace_probe_event. However, since it introduced a flexible
data structure with char array and type casting, the
alignment of trace_uprobe_filter can be broken.

This changes the type of the array to trace_uprobe_filter
data strucure to fix it.

Link: http://lore.kernel.org/r/20200120124022.GA14897@hirez.programming.kicks-ass.net
Link: http://lkml.kernel.org/r/157966340499.5107.10978352478952144902.stgit@devnote2

Fixes: 99c9a923e97a ("tracing/uprobe: Fix double perf_event linking on multiprobe uprobe")
Suggested-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Signed-off-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracing: Do not set trace clock if tracefs lockdown is in effect</title>
<updated>2020-01-20T21:18:14Z</updated>
<author>
<name>Masami Ichikawa</name>
<email>masami256@gmail.com</email>
</author>
<published>2020-01-16T13:12:36Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=bf24daac8f2bd5b8affaec03c2be1d20bcdd6837'/>
<id>urn:sha1:bf24daac8f2bd5b8affaec03c2be1d20bcdd6837</id>
<content type='text'>
When trace_clock option is not set and unstable clcok detected,
tracing_set_default_clock() sets trace_clock(ThinkPad A285 is one of
case). In that case, if lockdown is in effect, null pointer
dereference error happens in ring_buffer_set_clock().

Link: http://lkml.kernel.org/r/20200116131236.3866925-1-masami256@gmail.com

Cc: stable@vger.kernel.org
Fixes: 17911ff38aa58 ("tracing: Add locked_down checks to the open calls of files created for tracefs")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1788488
Signed-off-by: Masami Ichikawa &lt;masami256@gmail.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracing: Fix histogram code when expression has same var as value</title>
<updated>2020-01-20T21:11:47Z</updated>
<author>
<name>Steven Rostedt (VMware)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2020-01-20T18:07:31Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=8bcebc77e85f3d7536f96845a0fe94b1dddb6af0'/>
<id>urn:sha1:8bcebc77e85f3d7536f96845a0fe94b1dddb6af0</id>
<content type='text'>
While working on a tool to convert SQL syntex into the histogram language of
the kernel, I discovered the following bug:

 # echo 'first u64 start_time u64 end_time pid_t pid u64 delta' &gt;&gt; synthetic_events
 # echo 'hist:keys=pid:start=common_timestamp' &gt; events/sched/sched_waking/trigger
 # echo 'hist:keys=next_pid:delta=common_timestamp-$start,start2=$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' &gt; events/sched/sched_switch/trigger

Would not display any histograms in the sched_switch histogram side.

But if I were to swap the location of

  "delta=common_timestamp-$start" with "start2=$start"

Such that the last line had:

 # echo 'hist:keys=next_pid:start2=$start,delta=common_timestamp-$start:onmatch(sched.sched_waking).trace(first,$start2,common_timestamp,next_pid,$delta)' &gt; events/sched/sched_switch/trigger

The histogram works as expected.

What I found out is that the expressions clear out the value once it is
resolved. As the variables are resolved in the order listed, when
processing:

  delta=common_timestamp-$start

The $start is cleared. When it gets to "start2=$start", it errors out with
"unresolved symbol" (which is silent as this happens at the location of the
trace), and the histogram is dropped.

When processing the histogram for variable references, instead of adding a
new reference for a variable used twice, use the same reference. That way,
not only is it more efficient, but the order will no longer matter in
processing of the variables.

From Tom Zanussi:

 "Just to clarify some more about what the problem was is that without
  your patch, we would have two separate references to the same variable,
  and during resolve_var_refs(), they'd both want to be resolved
  separately, so in this case, since the first reference to start wasn't
  part of an expression, it wouldn't get the read-once flag set, so would
  be read normally, and then the second reference would do the read-once
  read and also be read but using read-once.  So everything worked and
  you didn't see a problem:

   from: start2=$start,delta=common_timestamp-$start

  In the second case, when you switched them around, the first reference
  would be resolved by doing the read-once, and following that the second
  reference would try to resolve and see that the variable had already
  been read, so failed as unset, which caused it to short-circuit out and
  not do the trigger action to generate the synthetic event:

   to: delta=common_timestamp-$start,start2=$start

  With your patch, we only have the single resolution which happens
  correctly the one time it's resolved, so this can't happen."

Link: https://lore.kernel.org/r/20200116154216.58ca08eb@gandalf.local.home

Cc: stable@vger.kernel.org
Fixes: 067fe038e70f6 ("tracing: Add variable reference handling to hist triggers")
Reviewed-by: Tom Zanuss &lt;zanussi@kernel.org&gt;
Tested-by: Tom Zanussi &lt;zanussi@kernel.org&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracing: trigger: Replace unneeded RCU-list traversals</title>
<updated>2020-01-14T22:12:04Z</updated>
<author>
<name>Masami Hiramatsu</name>
<email>mhiramat@kernel.org</email>
</author>
<published>2019-12-20T02:31:43Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=aeed8aa3874dc15b9d82a6fe796fd7cfbb684448'/>
<id>urn:sha1:aeed8aa3874dc15b9d82a6fe796fd7cfbb684448</id>
<content type='text'>
With CONFIG_PROVE_RCU_LIST, I had many suspicious RCU warnings
when I ran ftracetest trigger testcases.

-----
  # dmesg -c &gt; /dev/null
  # ./ftracetest test.d/trigger
  ...
  # dmesg | grep "RCU-list traversed" | cut -f 2 -d ] | cut -f 2 -d " "
  kernel/trace/trace_events_hist.c:6070
  kernel/trace/trace_events_hist.c:1760
  kernel/trace/trace_events_hist.c:5911
  kernel/trace/trace_events_trigger.c:504
  kernel/trace/trace_events_hist.c:1810
  kernel/trace/trace_events_hist.c:3158
  kernel/trace/trace_events_hist.c:3105
  kernel/trace/trace_events_hist.c:5518
  kernel/trace/trace_events_hist.c:5998
  kernel/trace/trace_events_hist.c:6019
  kernel/trace/trace_events_hist.c:6044
  kernel/trace/trace_events_trigger.c:1500
  kernel/trace/trace_events_trigger.c:1540
  kernel/trace/trace_events_trigger.c:539
  kernel/trace/trace_events_trigger.c:584
-----

I investigated those warnings and found that the RCU-list
traversals in event trigger and hist didn't need to use
RCU version because those were called only under event_mutex.

I also checked other RCU-list traversals related to event
trigger list, and found that most of them were called from
event_hist_trigger_func() or hist_unregister_trigger() or
register/unregister functions except for a few cases.

Replace these unneeded RCU-list traversals with normal list
traversal macro and lockdep_assert_held() to check the
event_mutex is held.

Link: http://lkml.kernel.org/r/157680910305.11685.15110237954275915782.stgit@devnote2

Cc: stable@vger.kernel.org
Fixes: 30350d65ac567 ("tracing: Add variable support to hist triggers")
Reviewed-by: Tom Zanussi &lt;zanussi@kernel.org&gt;
Signed-off-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracing/uprobe: Fix double perf_event linking on multiprobe uprobe</title>
<updated>2020-01-14T20:57:59Z</updated>
<author>
<name>Masami Hiramatsu</name>
<email>mhiramat@kernel.org</email>
</author>
<published>2020-01-10T01:45:39Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=99c9a923e97a583a38050baa92c9377d73946330'/>
<id>urn:sha1:99c9a923e97a583a38050baa92c9377d73946330</id>
<content type='text'>
Fix double perf_event linking to trace_uprobe_filter on
multiple uprobe event by moving trace_uprobe_filter under
trace_probe_event.

In uprobe perf event, trace_uprobe_filter data structure is
managing target mm filters (in perf_event) related to each
uprobe event.

Since commit 60d53e2c3b75 ("tracing/probe: Split trace_event
related data from trace_probe") left the trace_uprobe_filter
data structure in trace_uprobe, if a trace_probe_event has
multiple trace_uprobe (multi-probe event), a perf_event is
added to different trace_uprobe_filter on each trace_uprobe.
This leads a linked list corruption.

To fix this issue, move trace_uprobe_filter to trace_probe_event
and link it once on each event instead of each probe.

Link: http://lkml.kernel.org/r/157862073931.1800.3800576241181489174.stgit@devnote2

Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: "Naveen N . Rao" &lt;naveen.n.rao@linux.ibm.com&gt;
Cc: Anil S Keshavamurthy &lt;anil.s.keshavamurthy@intel.com&gt;
Cc: "David S . Miller" &lt;davem@davemloft.net&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Cc: =?utf-8?q?Toke_H=C3=B8iland-J?= =?utf-8?b?w7hyZ2Vuc2Vu?= &lt;thoiland@redhat.com&gt;
Cc: Jean-Tsung Hsiao &lt;jhsiao@redhat.com&gt;
Cc: Jesper Dangaard Brouer &lt;brouer@redhat.com&gt;
Cc: stable@vger.kernel.org
Fixes: 60d53e2c3b75 ("tracing/probe: Split trace_event related data from trace_probe")
Link: https://lkml.kernel.org/r/20200108171611.GA8472@kernel.org
Reported-by: Arnaldo Carvalho de Melo &lt;acme@kernel.org&gt;
Tested-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Signed-off-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracing: Fix indentation issue</title>
<updated>2020-01-03T20:20:46Z</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2019-12-21T15:48:25Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=72879ee0c53e2fc17f443f7b1adcc0d5130cd934'/>
<id>urn:sha1:72879ee0c53e2fc17f443f7b1adcc0d5130cd934</id>
<content type='text'>
There is a declaration that is indented one level too deeply, remove
the extraneous tab.

Link: http://lkml.kernel.org/r/20191221154825.33073-1-colin.king@canonical.com

Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>kernel/trace: Fix do not unregister tracepoints when register sched_migrate_task fail</title>
<updated>2020-01-03T16:43:03Z</updated>
<author>
<name>Kaitao Cheng</name>
<email>pilgrimtao@gmail.com</email>
</author>
<published>2019-12-31T13:35:30Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=50f9ad607ea891a9308e67b81f774c71736d1098'/>
<id>urn:sha1:50f9ad607ea891a9308e67b81f774c71736d1098</id>
<content type='text'>
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;
</content>
</entry>
<entry>
<title>ftrace: Avoid potential division by zero in function profiler</title>
<updated>2020-01-03T03:14:57Z</updated>
<author>
<name>Wen Yang</name>
<email>wenyang@linux.alibaba.com</email>
</author>
<published>2020-01-03T03:02:48Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=e31f7939c1c27faa5d0e3f14519eaf7c89e8a69d'/>
<id>urn:sha1:e31f7939c1c27faa5d0e3f14519eaf7c89e8a69d</id>
<content type='text'>
The ftrace_profile-&gt;counter is unsigned long and
do_div truncates it to 32 bits, which means it can test
non-zero and be truncated to zero for division.
Fix this issue by using div64_ul() instead.

Link: http://lkml.kernel.org/r/20200103030248.14516-1-wenyang@linux.alibaba.com

Cc: stable@vger.kernel.org
Fixes: e330b3bcd8319 ("tracing: Show sample std dev in function profiling")
Fixes: 34886c8bc590f ("tracing: add average time in function to function profiler")
Signed-off-by: Wen Yang &lt;wenyang@linux.alibaba.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracing: Have stack tracer compile when MCOUNT_INSN_SIZE is not defined</title>
<updated>2020-01-03T03:04:07Z</updated>
<author>
<name>Steven Rostedt (VMware)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2020-01-03T03:02:41Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b8299d362d0837ae39e87e9019ebe6b736e0f035'/>
<id>urn:sha1:b8299d362d0837ae39e87e9019ebe6b736e0f035</id>
<content type='text'>
On some archs with some configurations, MCOUNT_INSN_SIZE is not defined, and
this makes the stack tracer fail to compile. Just define it to zero in this
case.

Link: https://lore.kernel.org/r/202001020219.zvE3vsty%lkp@intel.com

Cc: stable@vger.kernel.org
Fixes: 4df297129f622 ("tracing: Remove most or all of stack tracer stack size from stack_max_size")
Reported-by: kbuild test robot &lt;lkp@intel.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>tracing: Define MCOUNT_INSN_SIZE when not defined without direct calls</title>
<updated>2020-01-03T02:56:44Z</updated>
<author>
<name>Steven Rostedt (VMware)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2020-01-03T02:56:44Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=d2ccbccb5444e9141b33cf5399927737e9ff1c3d'/>
<id>urn:sha1:d2ccbccb5444e9141b33cf5399927737e9ff1c3d</id>
<content type='text'>
In order to handle direct calls along side of function graph tracer, a check
is made to see if the address being traced by the function graph tracer is a
direct call or not. To get the address used by direct callers, the return
address is subtracted by MCOUNT_INSN_SIZE.

For some archs with certain configurations, MCOUNT_INSN_SIZE is undefined
here. But these should not be using direct calls anyway. Just define
MCOUNT_INSN_SIZE to zero in this case.

Link: https://lore.kernel.org/r/202001020219.zvE3vsty%lkp@intel.com

Reported-by: kbuild test robot &lt;lkp@intel.com&gt;
Fixes: ff205766dbbee ("ftrace: Fix function_graph tracer interaction with BPF trampoline")
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
</content>
</entry>
</feed>
