From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Namhyung Kim <namhyung@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>, Oleg Nesterov <oleg@redhat.com>,
Seth Jennings <sjenning@redhat.com>, Jiri Slaby <jslaby@suse.cz>
Subject: Re: [RFC][PATCH 0/3] ftrace: Add dynamically allocated trampolines
Date: Fri, 11 Jul 2014 09:29:28 -0500 [thread overview]
Message-ID: <20140711142928.GA13037@treble.redhat.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1407111523270.8779@pobox.suse.cz>
On Fri, Jul 11, 2014 at 03:24:28PM +0200, Jiri Kosina wrote:
> On Fri, 11 Jul 2014, Masami Hiramatsu wrote:
>
> > >> I did some testing with kpatch and I found one minor issue. The dynamically
> > >> allocated trampoline seems to confuse dump_stack() somewhat.
> > >>
> > >> I added a dump_stack() call in my ftrace_ops callback function
> > >> (kpatch_ftrace_handler) which had a filter on meminfo_proc_show().
> > >
> > > Interesting. Are you using dwarf2 unwinder for stack dumping by any
> > > chance? It seems to get things right here. Will look into it more
> > > tomorrow.
> >
> > Hmm, can dwarf2 unwinder work on the trampoline method? Since the
> > trampoline just a copy of instructions which will not have CFI(which is
> > stored in dwarf section), I guess it may not work... Frame pointer (push
> > bp and save sp to bp on the entry) can work anyway.
>
> That was exactly my idea and that's why I asked, thanks for confirming.
>
> I am afraid we'll have to declare dynamic trampolines incompatible with
> drawf2 stack dumping.
In this case, the problem wasn't related to DWARF, because dump_stack()
uses the frame pointer to unwind the stack. I was able to fix the
problem with the following patch.
---
>From 951d2aec17885a62905df6b910dc705d99c63993 Mon Sep 17 00:00:00 2001
From: Josh Poimboeuf <jpoimboe@redhat.com>
Date: Fri, 11 Jul 2014 08:58:33 -0500
Subject: [PATCH] x86/dumpstack: fix stack traces for generated code
If a function in the stack trace is dynamically generated, for example an
ftrace dynamically generated trampoline, print_context_stack() gets confused
and ends up showing all the following addresses as unreliable:
[ 934.546013] [<ffffffff81700312>] dump_stack+0x45/0x56
[ 934.546020] [<ffffffff8125f5b0>] ? meminfo_proc_open+0x30/0x30
[ 934.546027] [<ffffffffa080a494>] kpatch_ftrace_handler+0x14/0xf0 [kpatch]
[ 934.546058] [<ffffffff812143ae>] ? seq_read+0x2de/0x3b0
[ 934.546062] [<ffffffff812143ae>] ? seq_read+0x2de/0x3b0
[ 934.546067] [<ffffffff8125f5b5>] ? meminfo_proc_show+0x5/0x5e0
[ 934.546071] [<ffffffff8125f5b5>] ? meminfo_proc_show+0x5/0x5e0
[ 934.546075] [<ffffffff8121423a>] ? seq_read+0x16a/0x3b0
[ 934.546081] [<ffffffff8125768d>] ? proc_reg_read+0x3d/0x80
[ 934.546088] [<ffffffff811f0668>] ? vfs_read+0x98/0x170
[ 934.546093] [<ffffffff811f1345>] ? SyS_read+0x55/0xd0
[ 934.546099] [<ffffffff81707969>] ? system_call_fastpath+0x16/0x1b
Once it encounters an address which is not in the kernel's text area, it gets
confused and stops updating the frame pointer.
The __kernel_text_address() check isn't needed when determining whether an
address is reliable. It's only needed when deciding whether to print an
unreliable address.
Here's the same stack trace with this patch:
[ 1314.612287] [<ffffffff81700312>] dump_stack+0x45/0x56
[ 1314.612290] [<ffffffff8125f5b0>] ? meminfo_proc_open+0x30/0x30
[ 1314.612293] [<ffffffffa080a494>] kpatch_ftrace_handler+0x14/0xf0 [kpatch]
[ 1314.612306] [<ffffffffa00160c4>] 0xffffffffa00160c3
[ 1314.612309] [<ffffffff812143ae>] ? seq_read+0x2de/0x3b0
[ 1314.612311] [<ffffffff812143ae>] ? seq_read+0x2de/0x3b0
[ 1314.612312] [<ffffffff8125f5b5>] ? meminfo_proc_show+0x5/0x5e0
[ 1314.612314] [<ffffffff8125f5b5>] ? meminfo_proc_show+0x5/0x5e0
[ 1314.612315] [<ffffffff8121423a>] ? seq_read+0x16a/0x3b0
[ 1314.612318] [<ffffffff8125768d>] proc_reg_read+0x3d/0x80
[ 1314.612320] [<ffffffff811f0668>] vfs_read+0x98/0x170
[ 1314.612322] [<ffffffff811f1345>] SyS_read+0x55/0xd0
[ 1314.612324] [<ffffffff81707969>] system_call_fastpath+0x16/0x1b
---
arch/x86/kernel/dumpstack.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index b74ebc7..db0a33c 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -102,14 +102,13 @@ print_context_stack(struct thread_info *tinfo,
unsigned long addr;
addr = *stack;
- if (__kernel_text_address(addr)) {
- if ((unsigned long) stack == bp + sizeof(long)) {
- ops->address(data, addr, 1);
- frame = frame->next_frame;
- bp = (unsigned long) frame;
- } else {
- ops->address(data, addr, 0);
- }
+ if ((unsigned long) stack == bp + sizeof(long)) {
+ ops->address(data, addr, 1);
+ frame = frame->next_frame;
+ bp = (unsigned long) frame;
+ print_ftrace_graph_addr(addr, data, ops, tinfo, graph);
+ } else if (__kernel_text_address(addr)) {
+ ops->address(data, addr, 0);
print_ftrace_graph_addr(addr, data, ops, tinfo, graph);
}
stack++;
--
1.9.3
next prev parent reply other threads:[~2014-07-11 14:29 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-03 20:07 [RFC][PATCH 0/3] ftrace: Add dynamically allocated trampolines Steven Rostedt
2014-07-03 20:07 ` [RFC][PATCH 1/3] ftrace/x86: Add dynamic allocated trampoline for ftrace_ops Steven Rostedt
2014-07-04 13:32 ` Masami Hiramatsu
2014-07-04 14:25 ` Steven Rostedt
2014-07-14 2:34 ` Masami Hiramatsu
2014-07-03 20:07 ` [RFC][PATCH 2/3] ftrace/x86: Show trampoline call function in enabled_functions Steven Rostedt
2014-07-03 20:07 ` [RFC][PATCH 3/3] ftrace/x86: Allow !CONFIG_PREEMPT dynamic ops to use allocated trampolines Steven Rostedt
2014-07-03 20:32 ` [RFC][PATCH 0/3] ftrace: Add dynamically " Steven Rostedt
2014-07-04 13:20 ` Masami Hiramatsu
2014-07-04 14:21 ` Steven Rostedt
2014-07-07 13:22 ` Jiri Kosina
2014-07-08 14:24 ` Steven Rostedt
2014-07-07 13:58 ` Jiri Kosina
2014-07-10 21:36 ` Josh Poimboeuf
2014-07-10 21:44 ` Jiri Kosina
2014-07-10 22:01 ` Josh Poimboeuf
2014-07-11 2:26 ` Masami Hiramatsu
2014-07-11 13:24 ` Jiri Kosina
2014-07-11 14:29 ` Josh Poimboeuf [this message]
2014-07-14 1:35 ` Masami Hiramatsu
2014-07-14 7:16 ` Namhyung Kim
2014-07-14 8:18 ` Masami Hiramatsu
2014-07-14 14:18 ` Namhyung Kim
2014-07-15 1:20 ` Masami Hiramatsu
2014-07-22 16:47 ` Oleg Nesterov
2014-07-22 19:02 ` Steven Rostedt
2014-07-23 12:08 ` Oleg Nesterov
2014-07-23 15:48 ` Steven Rostedt
2014-07-23 17:05 ` Oleg Nesterov
2014-07-23 17:20 ` 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=20140711142928.GA13037@treble.redhat.com \
--to=jpoimboe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=jkosina@suse.cz \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
--cc=sjenning@redhat.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.