public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org
Cc: Ingo Molnar <mingo@elte.hu>, Andrew Morton <akpm@linux-foundation.org>
Subject: [PATCH 01/10] tracing: remove CALLER_ADDR2 from wakeup tracer
Date: Mon, 06 Apr 2009 12:37:07 -0400	[thread overview]
Message-ID: <20090406163829.878419451@goodmis.org> (raw)
In-Reply-To: 20090406163706.097842409@goodmis.org

[-- Attachment #1: 0001-tracing-remove-CALLER_ADDR2-from-wakeup-tracer.patch --]
[-- Type: text/plain, Size: 2922 bytes --]

From: Steven Rostedt <srostedt@redhat.com>

Maneesh Soni was getting a crash when running the wakeup tracer.
We debugged it down to the recording of the function with the
CALLER_ADDR2 macro.  This is used to get the location of the caller
to schedule.

But the problem comes when schedule is called by assmebly. In the case
that Maneesh had, retint_careful would call schedule. But retint_careful
does not set up a proper frame pointer. CALLER_ADDR2 is defined as
__builtin_return_address(2). This produces the following assembly in
the wakeup tracer code.

   mov    0x0(%rbp),%rcx  <--- get the frame pointer of the caller
   mov    %r14d,%r8d
   mov    0xf2de8e(%rip),%rdi

   mov    0x8(%rcx),%rsi  <-- this is __builtin_return_address(1)
   mov    0x28(%rdi,%rax,8),%rbx

   mov    (%rcx),%rax  <-- get the frame pointer of the caller's caller
   mov    %r12,%rcx
   mov    0x8(%rax),%rdx <-- this is __builtin_return_address(2)

At the reading of 0x8(%rax) Maneesh's machine would take a fault.
The reason is that retint_careful did not set up the return address
and the content of %rax here was zero.

To verify this, I sent Maneesh a patch to create a frame pointer
in retint_careful. He ran the test again but this time he would take
the same type of fault from sysret_careful. The retint_careful was no
longer an issue, but there are other callers that still have issues.

Instead of adding frame pointers for all callers to schedule (in possibly
all archs), it is much safer to simply not use CALLER_ADDR2. This
loses out on knowing what called schedule, but the function tracer
will help there if needed.

Reported-by: Maneesh Soni <maneesh@in.ibm.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
---
 kernel/trace/trace_sched_wakeup.c |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/kernel/trace/trace_sched_wakeup.c b/kernel/trace/trace_sched_wakeup.c
index 3c5ad6b..5bc00e8 100644
--- a/kernel/trace/trace_sched_wakeup.c
+++ b/kernel/trace/trace_sched_wakeup.c
@@ -154,7 +154,7 @@ probe_wakeup_sched_switch(struct rq *rq, struct task_struct *prev,
 	if (unlikely(!tracer_enabled || next != wakeup_task))
 		goto out_unlock;
 
-	trace_function(wakeup_trace, CALLER_ADDR1, CALLER_ADDR2, flags, pc);
+	trace_function(wakeup_trace, CALLER_ADDR0, CALLER_ADDR1, flags, pc);
 	tracing_sched_switch_trace(wakeup_trace, prev, next, flags, pc);
 
 	/*
@@ -257,6 +257,12 @@ probe_wakeup(struct rq *rq, struct task_struct *p, int success)
 	data = wakeup_trace->data[wakeup_cpu];
 	data->preempt_timestamp = ftrace_now(cpu);
 	tracing_sched_wakeup_trace(wakeup_trace, p, current, flags, pc);
+
+	/*
+	 * We must be careful in using CALLER_ADDR2. But since wake_up
+	 * is not called by an assembly function  (where as schedule is)
+	 * it should be safe to use it here.
+	 */
 	trace_function(wakeup_trace, CALLER_ADDR1, CALLER_ADDR2, flags, pc);
 
 out_locked:
-- 
1.6.2.1

-- 

  reply	other threads:[~2009-04-06 16:38 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-06 16:37 [PATCH 00/10] [GIT PULL] for tip/tracing/core Steven Rostedt
2009-04-06 16:37 ` Steven Rostedt [this message]
2009-04-06 16:37 ` [PATCH 02/10] tracing: use macros to denote usec and nsec per second Steven Rostedt
2009-04-06 16:37 ` [PATCH 03/10] tracing: fix incorrect return type of ns2usecs() V2 Steven Rostedt
2009-04-06 16:37 ` [PATCH 04/10] tracing/ftrace: fix missing include string.h Steven Rostedt
2009-04-06 16:37 ` [PATCH 05/10] tracing/ftrace: factorize the tracing files creation Steven Rostedt
2009-04-07 12:23   ` Ingo Molnar
2009-04-07 19:19     ` Steven Rostedt
2009-04-06 16:37 ` [PATCH 06/10] function-graph: add proper initialization for init task Steven Rostedt
2009-04-06 16:37 ` [PATCH 07/10] function-graph: use int instead of atomic for ftrace_graph_active Steven Rostedt
2009-04-06 16:37 ` [PATCH 08/10] ftrace: Add check of sched_stopped for probe_sched_wakeup Steven Rostedt
2009-04-06 16:37 ` [PATCH 09/10] ftrace: Clean up enable logic for sched_switch Steven Rostedt
2009-04-06 16:37 ` [PATCH 10/10] tracing, x86: remove duplicated #include Steven Rostedt
2009-04-07 11:56 ` [PATCH 00/10] [GIT PULL] for tip/tracing/core Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2009-04-04  0:27 [PATCH 00/10] [GIT PULL] updates for tip/tracing/ftrace Steven Rostedt
2009-04-04  0:27 ` [PATCH 01/10] tracing: remove CALLER_ADDR2 from wakeup tracer Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090406163829.878419451@goodmis.org \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox