<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/kernel/trace/trace.c, branch v4.4.130</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.130</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.130'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2018-01-02T19:33:22Z</updated>
<entry>
<title>tracing: Fix crash when it fails to alloc ring buffer</title>
<updated>2018-01-02T19:33:22Z</updated>
<author>
<name>Jing Xia</name>
<email>jing.xia@spreadtrum.com</email>
</author>
<published>2017-12-26T07:12:53Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=25fade614be3c72573eb914933e715cfaedae089'/>
<id>urn:sha1:25fade614be3c72573eb914933e715cfaedae089</id>
<content type='text'>
commit 24f2aaf952ee0b59f31c3a18b8b36c9e3d3c2cf5 upstream.

Double free of the ring buffer happens when it fails to alloc new
ring buffer instance for max_buffer if TRACER_MAX_TRACE is configured.
The root cause is that the pointer is not set to NULL after the buffer
is freed in allocate_trace_buffers(), and the freeing of the ring
buffer is invoked again later if the pointer is not equal to Null,
as:

instance_mkdir()
    |-allocate_trace_buffers()
        |-allocate_trace_buffer(tr, &amp;tr-&gt;trace_buffer...)
	|-allocate_trace_buffer(tr, &amp;tr-&gt;max_buffer...)

          // allocate fail(-ENOMEM),first free
          // and the buffer pointer is not set to null
        |-ring_buffer_free(tr-&gt;trace_buffer.buffer)

       // out_free_tr
    |-free_trace_buffers()
        |-free_trace_buffer(&amp;tr-&gt;trace_buffer);

	      //if trace_buffer is not null, free again
	    |-ring_buffer_free(buf-&gt;buffer)
                |-rb_free_cpu_buffer(buffer-&gt;buffers[cpu])
                    // ring_buffer_per_cpu is null, and
                    // crash in ring_buffer_per_cpu-&gt;pages

Link: http://lkml.kernel.org/r/20171226071253.8968-1-chunyan.zhang@spreadtrum.com

Fixes: 737223fbca3b1 ("tracing: Consolidate buffer allocation code")
Signed-off-by: Jing Xia &lt;jing.xia@spreadtrum.com&gt;
Signed-off-by: Chunyan Zhang &lt;chunyan.zhang@spreadtrum.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>tracing: Fix possible double free on failure of allocating trace buffer</title>
<updated>2018-01-02T19:33:22Z</updated>
<author>
<name>Steven Rostedt (VMware)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2017-12-27T01:07:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c2a62f84d49ff71cd7ffbe898c706ccc39955218'/>
<id>urn:sha1:c2a62f84d49ff71cd7ffbe898c706ccc39955218</id>
<content type='text'>
commit 4397f04575c44e1440ec2e49b6302785c95fd2f8 upstream.

Jing Xia and Chunyan Zhang reported that on failing to allocate part of the
tracing buffer, memory is freed, but the pointers that point to them are not
initialized back to NULL, and later paths may try to free the freed memory
again. Jing and Chunyan fixed one of the locations that does this, but
missed a spot.

Link: http://lkml.kernel.org/r/20171226071253.8968-1-chunyan.zhang@spreadtrum.com

Fixes: 737223fbca3b1 ("tracing: Consolidate buffer allocation code")
Reported-by: Jing Xia &lt;jing.xia@spreadtrum.com&gt;
Reported-by: Chunyan Zhang &lt;chunyan.zhang@spreadtrum.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>tracing: Remove extra zeroing out of the ring buffer page</title>
<updated>2018-01-02T19:33:21Z</updated>
<author>
<name>Steven Rostedt (VMware)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2017-12-23T01:38:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0752421016279f5ba7477e715e2e56a22028f93f'/>
<id>urn:sha1:0752421016279f5ba7477e715e2e56a22028f93f</id>
<content type='text'>
commit 6b7e633fe9c24682df550e5311f47fb524701586 upstream.

The ring_buffer_read_page() takes care of zeroing out any extra data in the
page that it returns. There's no need to zero it out again from the
consumer. It was removed from one consumer of this function, but
read_buffers_splice_read() did not remove it, and worse, it contained a
nasty bug because of it.

Fixes: 2711ca237a084 ("ring-buffer: Move zeroing out excess in page to ring buffer code")
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>tracing: Allocate mask_str buffer dynamically</title>
<updated>2017-12-20T09:04:51Z</updated>
<author>
<name>Changbin Du</name>
<email>changbin.du@intel.com</email>
</author>
<published>2017-11-30T03:39:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a34419b3f6a277b4da240f7b7a5e8be4d5c2356b'/>
<id>urn:sha1:a34419b3f6a277b4da240f7b7a5e8be4d5c2356b</id>
<content type='text'>
commit 90e406f96f630c07d631a021fd4af10aac913e77 upstream.

The default NR_CPUS can be very large, but actual possible nr_cpu_ids
usually is very small. For my x86 distribution, the NR_CPUS is 8192 and
nr_cpu_ids is 4. About 2 pages are wasted.

Most machines don't have so many CPUs, so define a array with NR_CPUS
just wastes memory. So let's allocate the buffer dynamically when need.

With this change, the mutext tracing_cpumask_update_lock also can be
removed now, which was used to protect mask_str.

Link: http://lkml.kernel.org/r/1512013183-19107-1-git-send-email-changbin.du@intel.com

Fixes: 36dfe9252bd4c ("ftrace: make use of tracing_cpumask")
Signed-off-by: Changbin Du &lt;changbin.du@intel.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>tracing: Erase irqsoff trace with empty write</title>
<updated>2017-10-05T07:41:44Z</updated>
<author>
<name>Bo Yan</name>
<email>byan@nvidia.com</email>
</author>
<published>2017-09-18T17:03:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=68a4a52899187a8411374b861ae1fed78302fab8'/>
<id>urn:sha1:68a4a52899187a8411374b861ae1fed78302fab8</id>
<content type='text'>
commit 8dd33bcb7050dd6f8c1432732f930932c9d3a33e upstream.

One convenient way to erase trace is "echo &gt; trace". However, this
is currently broken if the current tracer is irqsoff tracer. This
is because irqsoff tracer use max_buffer as the default trace
buffer.

Set the max_buffer as the one to be cleared when it's the trace
buffer currently in use.

Link: http://lkml.kernel.org/r/1505754215-29411-1-git-send-email-byan@nvidia.com

Cc: &lt;mingo@redhat.com&gt;
Fixes: 4acd4d00f ("tracing: give easy way to clear trace buffer")
Signed-off-by: Bo Yan &lt;byan@nvidia.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>tracing: Fix trace_pipe behavior for instance traces</title>
<updated>2017-10-05T07:41:44Z</updated>
<author>
<name>Tahsin Erdogan</name>
<email>tahsin@google.com</email>
</author>
<published>2017-09-17T10:23:48Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9c5afa726a526b2fb07cf0df922f2a959b3815bf'/>
<id>urn:sha1:9c5afa726a526b2fb07cf0df922f2a959b3815bf</id>
<content type='text'>
commit 75df6e688ccd517e339a7c422ef7ad73045b18a2 upstream.

When reading data from trace_pipe, tracing_wait_pipe() performs a
check to see if tracing has been turned off after some data was read.
Currently, this check always looks at global trace state, but it
should be checking the trace instance where trace_pipe is located at.

Because of this bug, cat instances/i1/trace_pipe in the following
script will immediately exit instead of waiting for data:

cd /sys/kernel/debug/tracing
echo 0 &gt; tracing_on
mkdir -p instances/i1
echo 1 &gt; instances/i1/tracing_on
echo 1 &gt; instances/i1/events/sched/sched_process_exec/enable
cat instances/i1/trace_pipe

Link: http://lkml.kernel.org/r/20170917102348.1615-1-tahsin@google.com

Fixes: 10246fa35d4f ("tracing: give easy way to clear trace buffer")
Signed-off-by: Tahsin Erdogan &lt;tahsin@google.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>tracing: Apply trace_clock changes to instance max buffer</title>
<updated>2017-09-27T09:00:16Z</updated>
<author>
<name>Baohong Liu</name>
<email>baohong.liu@intel.com</email>
</author>
<published>2017-09-05T21:57:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d28e96be7c6a2a4310c83c13054475836f6ffbae'/>
<id>urn:sha1:d28e96be7c6a2a4310c83c13054475836f6ffbae</id>
<content type='text'>
commit 170b3b1050e28d1ba0700e262f0899ffa4fccc52 upstream.

Currently trace_clock timestamps are applied to both regular and max
buffers only for global trace. For instance trace, trace_clock
timestamps are applied only to regular buffer. But, regular and max
buffers can be swapped, for example, following a snapshot. So, for
instance trace, bad timestamps can be seen following a snapshot.
Let's apply trace_clock timestamps to instance max buffer as well.

Link: http://lkml.kernel.org/r/ebdb168d0be042dcdf51f81e696b17fabe3609c1.1504642143.git.tom.zanussi@linux.intel.com

Fixes: 277ba0446 ("tracing: Add interface to allow multiple trace buffers")
Signed-off-by: Baohong Liu &lt;baohong.liu@intel.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>tracing: Fix kmemleak in instance_rmdir</title>
<updated>2017-07-27T22:06:10Z</updated>
<author>
<name>Chunyu Hu</name>
<email>chuhu@redhat.com</email>
</author>
<published>2017-07-20T10:36:09Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bb8109a9ca87f4b02a96002efabc30396ebe8eb5'/>
<id>urn:sha1:bb8109a9ca87f4b02a96002efabc30396ebe8eb5</id>
<content type='text'>
commit db9108e054700c96322b0f0028546aa4e643cf0b upstream.

Hit the kmemleak when executing instance_rmdir, it forgot releasing
mem of tracing_cpumask. With this fix, the warn does not appear any
more.

unreferenced object 0xffff93a8dfaa7c18 (size 8):
  comm "mkdir", pid 1436, jiffies 4294763622 (age 9134.308s)
  hex dump (first 8 bytes):
    ff ff ff ff ff ff ff ff                          ........
  backtrace:
    [&lt;ffffffff88b6567a&gt;] kmemleak_alloc+0x4a/0xa0
    [&lt;ffffffff8861ea41&gt;] __kmalloc_node+0xf1/0x280
    [&lt;ffffffff88b505d3&gt;] alloc_cpumask_var_node+0x23/0x30
    [&lt;ffffffff88b5060e&gt;] alloc_cpumask_var+0xe/0x10
    [&lt;ffffffff88571ab0&gt;] instance_mkdir+0x90/0x240
    [&lt;ffffffff886e5100&gt;] tracefs_syscall_mkdir+0x40/0x70
    [&lt;ffffffff886565c9&gt;] vfs_mkdir+0x109/0x1b0
    [&lt;ffffffff8865b1d0&gt;] SyS_mkdir+0xd0/0x100
    [&lt;ffffffff88403857&gt;] do_syscall_64+0x67/0x150
    [&lt;ffffffff88b710e7&gt;] return_from_SYSCALL_64+0x0/0x6a
    [&lt;ffffffffffffffff&gt;] 0xffffffffffffffff

Link: http://lkml.kernel.org/r/1500546969-12594-1-git-send-email-chuhu@redhat.com

Fixes: ccfe9e42e451 ("tracing: Make tracing_cpumask available for all instances")
Signed-off-by: Chunyu Hu &lt;chuhu@redhat.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>tracing: Use SOFTIRQ_OFFSET for softirq dectection for more accurate results</title>
<updated>2017-07-21T05:44:59Z</updated>
<author>
<name>Pavankumar Kondeti</name>
<email>pkondeti@codeaurora.org</email>
</author>
<published>2016-12-09T16:20:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=999b96b4de81a984bc94302b9ab7cad9f45eb6df'/>
<id>urn:sha1:999b96b4de81a984bc94302b9ab7cad9f45eb6df</id>
<content type='text'>
commit c59f29cb144a6a0dfac16ede9dc8eafc02dc56ca upstream.

The 's' flag is supposed to indicate that a softirq is running. This
can be detected by testing the preempt_count with SOFTIRQ_OFFSET.

The current code tests the preempt_count with SOFTIRQ_MASK, which
would be true even when softirqs are disabled but not serving a
softirq.

Link: http://lkml.kernel.org/r/1481300417-3564-1-git-send-email-pkondeti@codeaurora.org

Signed-off-by: Pavankumar Kondeti &lt;pkondeti@codeaurora.org&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Amit Pundir &lt;amit.pundir@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>tracing: Allocate the snapshot buffer before enabling probe</title>
<updated>2017-04-27T07:09:31Z</updated>
<author>
<name>Steven Rostedt (VMware)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2017-04-19T16:07:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1dfb1c7bd63f7ea8975f32ddd04a9c4406f8d64d'/>
<id>urn:sha1:1dfb1c7bd63f7ea8975f32ddd04a9c4406f8d64d</id>
<content type='text'>
commit df62db5be2e5f070ecd1a5ece5945b590ee112e0 upstream.

Currently the snapshot trigger enables the probe and then allocates the
snapshot. If the probe triggers before the allocation, it could cause the
snapshot to fail and turn tracing off. It's best to allocate the snapshot
buffer first, and then enable the trigger. If something goes wrong in the
enabling of the trigger, the snapshot buffer is still allocated, but it can
also be freed by the user by writting zero into the snapshot buffer file.

Also add a check of the return status of alloc_snapshot().

Fixes: 77fd5c15e3 ("tracing: Add snapshot trigger to function probes")
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
