<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/kernel/trace, branch v2.6.35.6</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/kernel/trace?h=v2.6.35.6</id>
<link rel='self' href='https://git.amat.us/linux/atom/kernel/trace?h=v2.6.35.6'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2010-09-20T20:36:34Z</updated>
<entry>
<title>tracing: t_start: reset FTRACE_ITER_HASH in case of seek/pread</title>
<updated>2010-09-20T20:36:34Z</updated>
<author>
<name>Chris Wright</name>
<email>chrisw@sous-sol.org</email>
</author>
<published>2010-09-09T23:34:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1b8c931cecdda5ce851b206e7dae5ff4470ec125'/>
<id>urn:sha1:1b8c931cecdda5ce851b206e7dae5ff4470ec125</id>
<content type='text'>
commit df09162550fbb53354f0c88e85b5d0e6129ee9cc upstream.

Be sure to avoid entering t_show() with FTRACE_ITER_HASH set without
having properly started the iterator to iterate the hash.  This case is
degenerate and, as discovered by Robert Swiecki, can cause t_hash_show()
to misuse a pointer.  This causes a NULL ptr deref with possible security
implications.  Tracked as CVE-2010-3079.

Cc: Robert Swiecki &lt;swiecki@google.com&gt;
Cc: Eugene Teo &lt;eugene@redhat.com&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>tracing: Do not allow llseek to set_ftrace_filter</title>
<updated>2010-09-20T20:36:33Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2010-09-08T15:20:37Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3c3d2da76db54975593ef526cbb17b94054c0fa2'/>
<id>urn:sha1:3c3d2da76db54975593ef526cbb17b94054c0fa2</id>
<content type='text'>
commit 9c55cb12c1c172e2d51e85fbb5a4796ca86b77e7 upstream.

Reading the file set_ftrace_filter does three things.

1) shows whether or not filters are set for the function tracer
2) shows what functions are set for the function tracer
3) shows what triggers are set on any functions

3 is independent from 1 and 2.

The way this file currently works is that it is a state machine,
and as you read it, it may change state. But this assumption breaks
when you use lseek() on the file. The state machine gets out of sync
and the t_show() may use the wrong pointer and cause a kernel oops.

Luckily, this will only kill the app that does the lseek, but the app
dies while holding a mutex. This prevents anyone else from using the
set_ftrace_filter file (or any other function tracing file for that matter).

A real fix for this is to rewrite the code, but that is too much for
a -rc release or stable. This patch simply disables llseek on the
set_ftrace_filter() file for now, and we can do the proper fix for the
next major release.

Reported-by: Robert Swiecki &lt;swiecki@google.com&gt;
Cc: Chris Wright &lt;chrisw@sous-sol.org&gt;
Cc: Tavis Ormandy &lt;taviso@google.com&gt;
Cc: Eugene Teo &lt;eugene@redhat.com&gt;
Cc: vendor-sec@lst.de
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>tracing: Fix a race in function profile</title>
<updated>2010-09-20T20:36:33Z</updated>
<author>
<name>Li Zefan</name>
<email>lizf@cn.fujitsu.com</email>
</author>
<published>2010-08-23T08:50:12Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b8536db269735d35d2b9a6480d40de212fed1b3c'/>
<id>urn:sha1:b8536db269735d35d2b9a6480d40de212fed1b3c</id>
<content type='text'>
commit 3aaba20f26f58843e8f20611e5c0b1c06954310f upstream.

While we are reading trace_stat/functionX and someone just
disabled function_profile at that time, we can trigger this:

	divide error: 0000 [#1] PREEMPT SMP
	...
	EIP is at function_stat_show+0x90/0x230
	...

This fix just takes the ftrace_profile_lock and checks if
rec-&gt;counter is 0. If it's 0, we know the profile buffer
has been reset.

Signed-off-by: Li Zefan &lt;lizf@cn.fujitsu.com&gt;
LKML-Reference: &lt;4C723644.4040708@cn.fujitsu.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>tracing: Fix ring_buffer_read_page reading out of page boundary</title>
<updated>2010-08-26T23:45:48Z</updated>
<author>
<name>Huang Ying</name>
<email>ying.huang@intel.com</email>
</author>
<published>2010-07-28T06:14:01Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=19d3c4671fabe2b80e6d449f88dd1822b6be66da'/>
<id>urn:sha1:19d3c4671fabe2b80e6d449f88dd1822b6be66da</id>
<content type='text'>
commit 18fab912d4fa70133df164d2dcf3310be0c38c34 upstream.

With the configuration: CONFIG_DEBUG_PAGEALLOC=y and Shaohua's patch:

[PATCH]x86: make spurious_fault check correct pte bit

Function call graph trace with the following will trigger a page fault.

# cd /sys/kernel/debug/tracing/
# echo function_graph &gt; current_tracer
# cat per_cpu/cpu1/trace_pipe_raw &gt; /dev/null

BUG: unable to handle kernel paging request at ffff880006e99000
IP: [&lt;ffffffff81085572&gt;] rb_event_length+0x1/0x3f
PGD 1b19063 PUD 1b1d063 PMD 3f067 PTE 6e99160
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
last sysfs file: /sys/devices/virtual/net/lo/operstate
CPU 1
Modules linked in:

Pid: 1982, comm: cat Not tainted 2.6.35-rc6-aes+ #300 /Bochs
RIP: 0010:[&lt;ffffffff81085572&gt;]  [&lt;ffffffff81085572&gt;] rb_event_length+0x1/0x3f
RSP: 0018:ffff880006475e38  EFLAGS: 00010006
RAX: 0000000000000ff0 RBX: ffff88000786c630 RCX: 000000000000001d
RDX: ffff880006e98000 RSI: 0000000000000ff0 RDI: ffff880006e99000
RBP: ffff880006475eb8 R08: 000000145d7008bd R09: 0000000000000000
R10: 0000000000008000 R11: ffffffff815d9336 R12: ffff880006d08000
R13: ffff880006e605d8 R14: 0000000000000000 R15: 0000000000000018
FS:  00007f2b83e456f0(0000) GS:ffff880002100000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff880006e99000 CR3: 00000000064a8000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process cat (pid: 1982, threadinfo ffff880006474000, task ffff880006e40770)
Stack:
 ffff880006475eb8 ffffffff8108730f 0000000000000ff0 000000145d7008bd
&lt;0&gt; ffff880006e98010 ffff880006d08010 0000000000000296 ffff88000786c640
&lt;0&gt; ffffffff81002956 0000000000000000 ffff8800071f4680 ffff8800071f4680
Call Trace:
 [&lt;ffffffff8108730f&gt;] ? ring_buffer_read_page+0x15a/0x24a
 [&lt;ffffffff81002956&gt;] ? return_to_handler+0x15/0x2f
 [&lt;ffffffff8108a575&gt;] tracing_buffers_read+0xb9/0x164
 [&lt;ffffffff810debfe&gt;] vfs_read+0xaf/0x150
 [&lt;ffffffff81002941&gt;] return_to_handler+0x0/0x2f
 [&lt;ffffffff810248b0&gt;] __bad_area_nosemaphore+0x17e/0x1a1
 [&lt;ffffffff81002941&gt;] return_to_handler+0x0/0x2f
 [&lt;ffffffff810248e6&gt;] bad_area_nosemaphore+0x13/0x15
Code: 80 25 b2 16 b3 00 fe c9 c3 55 48 89 e5 f0 80 0d a4 16 b3 00 02 c9 c3 55 31 c0 48 89 e5 48 83 3d 94 16 b3 00 01 c9 0f 94 c0 c3 55 &lt;8a&gt; 0f 48 89 e5 83 e1 1f b8 08 00 00 00 0f b6 d1 83 fa 1e 74 27
RIP  [&lt;ffffffff81085572&gt;] rb_event_length+0x1/0x3f
 RSP &lt;ffff880006475e38&gt;
CR2: ffff880006e99000
---[ end trace a6877bb92ccb36bb ]---

The root cause is that ring_buffer_read_page() may read out of page
boundary, because the boundary checking is done after reading. This is
fixed via doing boundary checking before reading.

Reported-by: Shaohua Li &lt;shaohua.li@intel.com&gt;
Signed-off-by: Huang Ying &lt;ying.huang@intel.com&gt;
LKML-Reference: &lt;1280297641.2771.307.camel@yhuang-dev&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>tracing: Fix an unallocated memory access in function_graph</title>
<updated>2010-08-26T23:45:48Z</updated>
<author>
<name>Shaohua Li</name>
<email>shaohua.li@intel.com</email>
</author>
<published>2010-07-27T08:06:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ee384c27819972c620c2eec0545b9f1472cbe0ab'/>
<id>urn:sha1:ee384c27819972c620c2eec0545b9f1472cbe0ab</id>
<content type='text'>
commit 575570f02761bd680ba5731c1dfd4701062e7fb2 upstream.

With CONFIG_DEBUG_PAGEALLOC, I observed an unallocated memory access in
function_graph trace. It appears we find a small size entry in ring buffer,
but we access it as a big size entry. The access overflows the page size
and touches an unallocated page.

Signed-off-by: Shaohua Li &lt;shaohua.li@intel.com&gt;
LKML-Reference: &lt;1280217994.32400.76.camel@sli10-desk.sh.intel.com&gt;
[ Added a comment to explain the problem - SDR ]
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>perf/tracing: Fix regression of perf losing kprobe events</title>
<updated>2010-06-11T00:56:54Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2010-06-10T18:53:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a8fb2608053547bc3152ea61a5ec7cdfce5d942c'/>
<id>urn:sha1:a8fb2608053547bc3152ea61a5ec7cdfce5d942c</id>
<content type='text'>
With the addition of the code to shrink the kernel tracepoint
infrastructure, we lost kprobes being traced by perf. The reason
is that I tested if the "tp_event-&gt;class-&gt;perf_probe" existed before
enabling it. This prevents "ftrace only" events (like the function
trace events) from being enabled by perf.

Unfortunately, kprobe events do not use perf_probe. This causes
kprobes to be missed by perf. To fix this, we add the test to
see if "tp_event-&gt;class-&gt;reg" exists as well as perf_probe.

Normal trace events have only "perf_probe" but no "reg" function,
and kprobes and syscalls have the "reg" but no "perf_probe".
The ftrace unique events do not have either, so this is a valid
test. If a kprobe or syscall is not to be probed by perf, the
"reg" function is called anyway, and will return a failure and
prevent perf from probing it.

Reported-by: Srikar Dronamraju &lt;srikar@linux.vnet.ibm.com&gt;
Tested-by: Srikar Dronamraju &lt;srikar@linux.vnet.ibm.com&gt;
Acked-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>blktrace: Fix new kernel-doc warnings</title>
<updated>2010-05-31T07:58:20Z</updated>
<author>
<name>Randy Dunlap</name>
<email>randy.dunlap@oracle.com</email>
</author>
<published>2010-05-29T18:45:07Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=546cf44a1b507c1cbb5cf42bbe6169780567f36f'/>
<id>urn:sha1:546cf44a1b507c1cbb5cf42bbe6169780567f36f</id>
<content type='text'>
Fix blktrace.c kernel-doc warnings:
 Warning(kernel/trace/blktrace.c:858): No description found for parameter 'ignore'
 Warning(kernel/trace/blktrace.c:890): No description found for parameter 'ignore'

Signed-off-by: Randy Dunlap &lt;randy.dunlap@oracle.com&gt;
Cc: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
LKML-Reference: &lt;20100529114507.c466fc1e.randy.dunlap@oracle.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>perf_events, trace: Fix perf_trace_destroy(), mutex went missing</title>
<updated>2010-05-31T06:46:09Z</updated>
<author>
<name>Peter Zijlstra</name>
<email>a.p.zijlstra@chello.nl</email>
</author>
<published>2010-05-21T14:22:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2e97942fe57864588774f173cf4cd7bb68968b76'/>
<id>urn:sha1:2e97942fe57864588774f173cf4cd7bb68968b76</id>
<content type='text'>
Steve spotted I forgot to do the destroy under event_mutex.

Reported-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
LKML-Reference: &lt;1274451913.1674.1707.camel@laptop&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>perf_events, trace: Fix probe unregister race</title>
<updated>2010-05-31T06:46:09Z</updated>
<author>
<name>Peter Zijlstra</name>
<email>a.p.zijlstra@chello.nl</email>
</author>
<published>2010-05-21T10:31:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=3771f0771154675d4a0ca780be2411f3cc357208'/>
<id>urn:sha1:3771f0771154675d4a0ca780be2411f3cc357208</id>
<content type='text'>
tracepoint_probe_unregister() does not synchronize against the probe
callbacks, so do that explicitly. This properly serializes the callbacks
and the free of the data used therein.

Also, use this_cpu_ptr() where possible.

Acked-by: Frederic Weisbecker &lt;fweisbec@gmail.com&gt;
Signed-off-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
LKML-Reference: &lt;1274438476.1674.1702.camel@laptop&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip</title>
<updated>2010-05-30T19:35:01Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2010-05-30T19:35:01Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bc7d352c5e76c74c628a39b99777a1bdddde5e81'/>
<id>urn:sha1:bc7d352c5e76c74c628a39b99777a1bdddde5e81</id>
<content type='text'>
* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  perf tui: Fix last use_browser problem related to .perfconfig
  perf symbols: Add the build id cache to the vmlinux path
  perf tui: Reset use_browser if stdout is not a tty
  ring-buffer: Move zeroing out excess in page to ring buffer code
  ring-buffer: Reset "real_end" when page is filled
</content>
</entry>
</feed>
