[PATCH 0/2] [GIT PULL] tracing: A couple of fixes

[PATCH 0/2] [GIT PULL] tracing: A couple of fixes

[Steven Rostedt]

Linus,

This contains two fixes.

The first is to remove a duplication of creating debugfs files that
already exist and causes an error report to be printed due to the
failure of the second creation.

The second is a memory leak fix that was introduced in 3.14.

Please pull the latest trace-fixes-v3.15-rc1 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-fixes-v3.15-rc1

Tag SHA1: cda50faf0eace20c60940638a550ecd5e9eac4c1
Head SHA1: 6ea6215fe394e320468589d9bba464a48f6d823a


Steven Rostedt (Red Hat) (1):
      tracing: Do not try to recreated toplevel set_ftrace_* files

zhangwei(Jovi) (1):
      tracing/uprobes: Fix uprobe_cpu_buffer memory leak

----
 kernel/trace/trace_functions.c | 16 ++++++++++------
 kernel/trace/trace_uprobe.c    |  6 ++++++
 2 files changed, 16 insertions(+), 6 deletions(-)

[PATCH 1/2] tracing: Do not try to recreated toplevel set_ftrace_* files

[Steven Rostedt]

[-- Attachment #1: 0001-tracing-Do-not-try-to-recreated-toplevel-set_ftrace_.patch --]
[-- Type: text/plain, Size: 1852 bytes --]

From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>

With the restructing of the function tracer working with instances, the
"top level" buffer is a bit special, as the function tracing is mapped
to the same set of filters. This is done by using a "global_ops" descriptor
and having the "set_ftrace_filter" and "set_ftrace_notrace" map to it.

When an instance is created, it creates the same files but its for the
local instance and not the global_ops.

The issues is that the local instance creation shares some code with
the global instance one and we end up trying to create th top level
"set_ftrace_*" files twice, and on boot up, we get an error like this:

 Could not create debugfs 'set_ftrace_filter' entry
 Could not create debugfs 'set_ftrace_notrace' entry

The reason they failed to be created was because they were created
twice, and the second time gives this error as you can not create the
same file twice.

Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 kernel/trace/trace_functions.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
index 5b781d2..ffd5635 100644
--- a/kernel/trace/trace_functions.c
+++ b/kernel/trace/trace_functions.c
@@ -58,12 +58,16 @@ int ftrace_create_function_files(struct trace_array *tr,
 {
 	int ret;
 
-	/* The top level array uses the "global_ops". */
-	if (!(tr->flags & TRACE_ARRAY_FL_GLOBAL)) {
-		ret = allocate_ftrace_ops(tr);
-		if (ret)
-			return ret;
-	}
+	/*
+	 * The top level array uses the "global_ops", and the files are
+	 * created on boot up.
+	 */
+	if (tr->flags & TRACE_ARRAY_FL_GLOBAL)
+		return 0;
+
+	ret = allocate_ftrace_ops(tr);
+	if (ret)
+		return ret;
 
 	ftrace_create_filter_files(tr->ops, parent);
 
-- 
1.8.5.3

[PATCH 2/2] tracing/uprobes: Fix uprobe_cpu_buffer memory leak

[Steven Rostedt]

[-- Attachment #1: 0002-tracing-uprobes-Fix-uprobe_cpu_buffer-memory-leak.patch --]
[-- Type: text/plain, Size: 1020 bytes --]

From: "zhangwei(Jovi)" <jovi.zhangwei@huawei.com>

Forgot to free uprobe_cpu_buffer percpu page in uprobe_buffer_disable().

Link: http://lkml.kernel.org/p/534F8B3F.1090407@huawei.com

Cc: stable@vger.kernel.org # v3.14+
Acked-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 kernel/trace/trace_uprobe.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index 930e514..c082a74 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -732,9 +732,15 @@ static int uprobe_buffer_enable(void)
 
 static void uprobe_buffer_disable(void)
 {
+	int cpu;
+
 	BUG_ON(!mutex_is_locked(&event_mutex));
 
 	if (--uprobe_buffer_refcnt == 0) {
+		for_each_possible_cpu(cpu)
+			free_page((unsigned long)per_cpu_ptr(uprobe_cpu_buffer,
+							     cpu)->buf);
+
 		free_percpu(uprobe_cpu_buffer);
 		uprobe_cpu_buffer = NULL;
 	}
-- 
1.8.5.3

Re: [PATCH 1/2] tracing: Do not try to recreated toplevel set_ftrace_* files

[Borislav Petkov]

On Thu, Apr 17, 2014 at 07:42:57PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
> 
> With the restructing of the function tracer working with instances, the
> "top level" buffer is a bit special, as the function tracing is mapped
> to the same set of filters. This is done by using a "global_ops" descriptor
> and having the "set_ftrace_filter" and "set_ftrace_notrace" map to it.
> 
> When an instance is created, it creates the same files but its for the
> local instance and not the global_ops.
> 
> The issues is that the local instance creation shares some code with
> the global instance one and we end up trying to create th top level
> "set_ftrace_*" files twice, and on boot up, we get an error like this:
> 
>  Could not create debugfs 'set_ftrace_filter' entry
>  Could not create debugfs 'set_ftrace_notrace' entry
> 
> The reason they failed to be created was because they were created
> twice, and the second time gives this error as you can not create the
> same file twice.
> 
> Reported-by: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Tested-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

[PATCH 0/2] [GIT PULL] tracing: A couple of fixes

[Steven Rostedt]

Linus,

This includes two fixes.

The first is something that has come up a few times and has been
worked out individually, but it's come up now enough that the problem
should be generic. Tracepoints are protected by RCU sched. There are
several tracepoints within core infrastructure like kfree().
If a tracepoint is called when the CPU is going down, or when it's
coming up but has yet to be recognized by RCU, a RCU warning is
triggered. This is a true bug as that tracepoint is not protected by
RCU. Usually, this is taken care of by testing for cpu online as
a tracepoint condition. But as this is happening more often, moving
it from a individual tracepoint to a check in the tracepoint infrastructure
is more robust.

Note, there is now a duplicate of a cpu online test, because this update
does not remove the individual checks. But the overhead is small enough
that the removal can be done in another release.

The second change is strange linker breakage due to the branch tracer's
builtin_constant_p() check failing, and treating the condition as a
variable instead of a constant. Arnd Bergmann found that this can be
fixed by testing !!(cond) instead of just (cond).

Please pull the latest trace-fixes-v4.5-rc4 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-fixes-v4.5-rc4

Tag SHA1: abfeb62bfa1a219b42a0e984db59f6535a741b17
Head SHA1: b33c8ff4431a343561e2319f17c14286f2aa52e2


Arnd Bergmann (1):
      tracing: Fix freak link error caused by branch tracer

Steven Rostedt (Red Hat) (1):
      tracepoints: Do not trace when cpu is offline

----
 include/linux/compiler.h   | 2 +-
 include/linux/tracepoint.h | 5 +++++
 2 files changed, 6 insertions(+), 1 deletion(-)

[PATCH 0/2] [GIT PULL] tracing: A couple of fixes

[Steven Rostedt]

[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]


Linus,

Two more fixes:

The first one was reported by Mauro Carvalho Chehab, where if a poll()
is done against a trace buffer for a CPU that has never been online,
it will crash the kernel, as buffers are only created when a CPU comes
on line, but the trace files are for all possible CPUs.

This fix is to check if the buffer was allocated and if not return -EINVAL.

That was the simple fix, the real fix is a bit more complex and not for
a -rc release. We could have the files created when the CPUs come online.
That would require some design changes.

The second one was reported by Peter Zijlstra. If the kernel command line
has ftrace=nop, it will lock up the system on boot up. This is because
the new design for 3.10 has the nop tracer bootstrap the tracing subsystem.
When ftrace=<trace> is defined, when that tracer is registered, it
starts the tracing, but uses the nop tracer to clear things out.
What happened here was that ftrace=nop caused the registering of nop
to start it and use nop before it was initialized.

The only thing nop needs to have done to initialize it is to have the
tracer point its current_tracer structure member to the nop tracer.
Doing that before registering the nop tracer makes everything work.

-- Steve

Please pull the latest trace-fixes-v3.10-rc3 tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-fixes-v3.10-rc3

Tag SHA1: fc1bb352c272393813d3081ba40a2921a519acdb
Head SHA1: 6721cb60022629ae76365551f05d9658b8d14c55


Steven Rostedt (Red Hat) (2):
      tracing: Fix crash when ftrace=nop on the kernel command line
      ring-buffer: Do not poll non allocated cpu buffers

----
 kernel/trace/ring_buffer.c |    3 +++
 kernel/trace/trace.c       |    9 +++++++--
 2 files changed, 10 insertions(+), 2 deletions(-)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]