From: AKASHI Takahiro <takahiro.akashi@linaro.org> To: catalin.marinas@arm.com, will.deacon@arm.com, rostedt@goodmis.org Cc: jungseoklee85@gmail.com, olof@lixom.net, broonie@kernel.org, david.griego@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, AKASHI Takahiro <takahiro.akashi@linaro.org> Subject: [RFC 0/3] arm64: ftrace: fix incorrect output from stack tracer Date: Mon, 13 Jul 2015 14:29:32 +0900 [thread overview] Message-ID: <1436765375-7119-1-git-send-email-takahiro.akashi@linaro.org> (raw) As reported in the thread below[1], the output from stack tracer using ftrace on arm64 seems to be incorrect due to different reasons. Each problem is described and fixed repsectively in the following patches. Please see the commit messages for the details. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354126.html If the patch[1/3], which adds "#ifdef CONFIG_ARM64" to generic ftrace code, is not acceptable, we will have to introduce an arch-dependent function, ie. arch_check_stack(). Even with those patches, we see another issue that the values in 'Size' field are *inaccurate*. This is simply because we have no way to estimate the value of stack pointer at each function from the content of stack. Thus the function's reported stack size does not include its own local variables, but includes *its child's* ones. See more details below. In my opinion, we cannot fix this issue unless analyzing the function's first instruction, ie. "stp x29, x30, [sp, #xx]!". * How does stack tracer identify each function's stack size? Take an example, func-0 calls func-1 and func-1 calls func-2. The stack layout looks like the below: ("p" is a temp variable in check_stack().) sp2 +-------+ <--------- func-2's stackframe | | | | fp2 +-------+ | fp1 | +-------+ <-- p1 (*p1 == stack_dump_trace[i] == lr1) | lr1 | +-------+ | | | func-2's local variables | | sp1 +-------+ <--------- func-1(lr1)'s stackframe | | (stack_dump_index[i] = top - p1) | func-1's dynamic local variables | | fp1 +-------+ | fp0 | +-------+ <-- p0 (*p0 == stack_dump_trace[i+1] == lr0) | lr0 | +-------+ | | | func-1's local variables | | sp0 +-------+ <--------- func-0(lr0)'s stackframe | | (stack_dump_index[i+1] = top - p0) | | *-------+ top Stack tracer records the stack height of func-1 (== stack_dump_trace[i]): stack_dump_index[i] = <stack top> - <estimated stack pointer> in check_stack() by searching for func-1's return address (lr1) and eventually calculates func-1's stack size by: stack_dump_index[i] - stack_dump_index[i+1] => (top - p1) - (top - p0) => p1 - p0 On x86, this calculation is correct because x86's call instruction pushes the return address to the stack and jump into the child(func-2) function, thus the func-1's stack pointer is "p1" where *p1 is equal to stack_dump_trace[i]. But this is not true on arm64. AKASHI Takahiro (3): ftrace: adjust a function's pc to search for in check_stack() for arm64 arm64: refactor save_stack_trace() arm64: ftrace: mcount() should not create a stack frame arch/arm64/kernel/entry-ftrace.S | 15 ++++++++------- arch/arm64/kernel/stacktrace.c | 31 +++++++++++++++++++++++-------- kernel/trace/trace_stack.c | 4 ++++ 3 files changed, 35 insertions(+), 15 deletions(-) -- 1.7.9.5
WARNING: multiple messages have this Message-ID (diff)
From: takahiro.akashi@linaro.org (AKASHI Takahiro) To: linux-arm-kernel@lists.infradead.org Subject: [RFC 0/3] arm64: ftrace: fix incorrect output from stack tracer Date: Mon, 13 Jul 2015 14:29:32 +0900 [thread overview] Message-ID: <1436765375-7119-1-git-send-email-takahiro.akashi@linaro.org> (raw) As reported in the thread below[1], the output from stack tracer using ftrace on arm64 seems to be incorrect due to different reasons. Each problem is described and fixed repsectively in the following patches. Please see the commit messages for the details. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354126.html If the patch[1/3], which adds "#ifdef CONFIG_ARM64" to generic ftrace code, is not acceptable, we will have to introduce an arch-dependent function, ie. arch_check_stack(). Even with those patches, we see another issue that the values in 'Size' field are *inaccurate*. This is simply because we have no way to estimate the value of stack pointer at each function from the content of stack. Thus the function's reported stack size does not include its own local variables, but includes *its child's* ones. See more details below. In my opinion, we cannot fix this issue unless analyzing the function's first instruction, ie. "stp x29, x30, [sp, #xx]!". * How does stack tracer identify each function's stack size? Take an example, func-0 calls func-1 and func-1 calls func-2. The stack layout looks like the below: ("p" is a temp variable in check_stack().) sp2 +-------+ <--------- func-2's stackframe | | | | fp2 +-------+ | fp1 | +-------+ <-- p1 (*p1 == stack_dump_trace[i] == lr1) | lr1 | +-------+ | | | func-2's local variables | | sp1 +-------+ <--------- func-1(lr1)'s stackframe | | (stack_dump_index[i] = top - p1) | func-1's dynamic local variables | | fp1 +-------+ | fp0 | +-------+ <-- p0 (*p0 == stack_dump_trace[i+1] == lr0) | lr0 | +-------+ | | | func-1's local variables | | sp0 +-------+ <--------- func-0(lr0)'s stackframe | | (stack_dump_index[i+1] = top - p0) | | *-------+ top Stack tracer records the stack height of func-1 (== stack_dump_trace[i]): stack_dump_index[i] = <stack top> - <estimated stack pointer> in check_stack() by searching for func-1's return address (lr1) and eventually calculates func-1's stack size by: stack_dump_index[i] - stack_dump_index[i+1] => (top - p1) - (top - p0) => p1 - p0 On x86, this calculation is correct because x86's call instruction pushes the return address to the stack and jump into the child(func-2) function, thus the func-1's stack pointer is "p1" where *p1 is equal to stack_dump_trace[i]. But this is not true on arm64. AKASHI Takahiro (3): ftrace: adjust a function's pc to search for in check_stack() for arm64 arm64: refactor save_stack_trace() arm64: ftrace: mcount() should not create a stack frame arch/arm64/kernel/entry-ftrace.S | 15 ++++++++------- arch/arm64/kernel/stacktrace.c | 31 +++++++++++++++++++++++-------- kernel/trace/trace_stack.c | 4 ++++ 3 files changed, 35 insertions(+), 15 deletions(-) -- 1.7.9.5
next reply other threads:[~2015-07-13 5:30 UTC|newest] Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-07-13 5:29 AKASHI Takahiro [this message] 2015-07-13 5:29 ` [RFC 0/3] arm64: ftrace: fix incorrect output from stack tracer AKASHI Takahiro 2015-07-13 5:29 ` [RFC 1/3] ftrace: adjust a function's pc to search for in check_stack() for arm64 AKASHI Takahiro 2015-07-13 5:29 ` AKASHI Takahiro 2015-07-13 15:24 ` Steven Rostedt 2015-07-13 15:24 ` Steven Rostedt 2015-07-15 0:22 ` AKASHI Takahiro 2015-07-15 0:22 ` AKASHI Takahiro 2015-07-13 5:29 ` [RFC 2/3] arm64: refactor save_stack_trace() AKASHI Takahiro 2015-07-13 5:29 ` AKASHI Takahiro 2015-07-14 12:47 ` Jungseok Lee 2015-07-14 12:47 ` Jungseok Lee 2015-07-14 13:31 ` Steven Rostedt 2015-07-14 13:31 ` Steven Rostedt 2015-07-15 0:20 ` AKASHI Takahiro 2015-07-15 0:20 ` AKASHI Takahiro 2015-07-15 2:51 ` Steven Rostedt 2015-07-15 2:51 ` Steven Rostedt 2015-07-15 11:41 ` AKASHI Takahiro 2015-07-15 11:41 ` AKASHI Takahiro 2015-07-15 14:55 ` Steven Rostedt 2015-07-15 14:55 ` Steven Rostedt 2015-07-15 16:13 ` Steven Rostedt 2015-07-15 16:13 ` Steven Rostedt 2015-07-16 0:27 ` AKASHI Takahiro 2015-07-16 0:27 ` AKASHI Takahiro 2015-07-16 1:08 ` AKASHI Takahiro 2015-07-16 1:08 ` AKASHI Takahiro 2015-07-16 1:38 ` Steven Rostedt 2015-07-16 1:38 ` Steven Rostedt 2015-07-17 10:46 ` Will Deacon 2015-07-17 10:46 ` Will Deacon 2015-07-16 13:29 ` Jungseok Lee 2015-07-16 13:29 ` Jungseok Lee 2015-07-16 13:54 ` Jungseok Lee 2015-07-16 13:54 ` Jungseok Lee 2015-07-16 14:24 ` Steven Rostedt 2015-07-16 14:24 ` Steven Rostedt 2015-07-16 15:01 ` Jungseok Lee 2015-07-16 15:01 ` Jungseok Lee 2015-07-16 15:31 ` Steven Rostedt 2015-07-16 15:31 ` Steven Rostedt 2015-07-16 15:52 ` Jungseok Lee 2015-07-16 15:52 ` Jungseok Lee 2015-07-16 20:22 ` Steven Rostedt 2015-07-16 20:22 ` Steven Rostedt 2015-07-17 2:49 ` AKASHI Takahiro 2015-07-17 2:49 ` AKASHI Takahiro 2015-07-17 3:21 ` Steven Rostedt 2015-07-17 3:21 ` Steven Rostedt 2015-07-16 16:16 ` Steven Rostedt 2015-07-16 16:16 ` Steven Rostedt 2015-07-17 12:40 ` Mark Rutland 2015-07-17 12:40 ` Mark Rutland 2015-07-17 12:51 ` Steven Rostedt 2015-07-17 12:51 ` Steven Rostedt 2015-07-17 13:00 ` Steven Rostedt 2015-07-17 13:00 ` Steven Rostedt 2015-07-17 14:28 ` Jungseok Lee 2015-07-17 14:28 ` Jungseok Lee 2015-07-17 14:41 ` Steven Rostedt 2015-07-17 14:41 ` Steven Rostedt 2015-07-17 14:59 ` Jungseok Lee 2015-07-17 14:59 ` Jungseok Lee 2015-07-17 15:34 ` Jungseok Lee 2015-07-17 15:34 ` Jungseok Lee 2015-07-17 16:01 ` Steven Rostedt 2015-07-17 16:01 ` Steven Rostedt 2015-07-20 16:20 ` Will Deacon 2015-07-20 16:20 ` Will Deacon 2015-07-20 23:53 ` AKASHI Takahiro 2015-07-20 23:53 ` AKASHI Takahiro 2015-07-21 10:26 ` AKASHI Takahiro 2015-07-21 10:26 ` AKASHI Takahiro 2015-07-21 14:34 ` Jungseok Lee 2015-07-21 14:34 ` Jungseok Lee 2015-08-03 9:09 ` Will Deacon 2015-08-03 9:09 ` Will Deacon 2015-08-03 14:01 ` Steven Rostedt 2015-08-03 14:01 ` Steven Rostedt 2015-08-03 14:04 ` Will Deacon 2015-08-03 14:04 ` Will Deacon 2015-08-03 16:30 ` Jungseok Lee 2015-08-03 16:30 ` Jungseok Lee 2015-08-03 16:57 ` Steven Rostedt 2015-08-03 16:57 ` Steven Rostedt 2015-08-03 17:22 ` Jungseok Lee 2015-08-03 17:22 ` Jungseok Lee 2015-08-03 17:32 ` Steven Rostedt 2015-08-03 17:32 ` Steven Rostedt 2015-08-04 7:41 ` AKASHI Takahiro 2015-08-04 7:41 ` AKASHI Takahiro 2015-07-17 2:04 ` AKASHI Takahiro 2015-07-17 2:04 ` AKASHI Takahiro 2015-07-17 14:38 ` Jungseok Lee 2015-07-17 14:38 ` Jungseok Lee 2015-07-16 14:28 ` Mark Rutland 2015-07-16 14:28 ` Mark Rutland 2015-07-16 14:34 ` Steven Rostedt 2015-07-16 14:34 ` Steven Rostedt 2015-07-17 2:09 ` AKASHI Takahiro 2015-07-17 2:09 ` AKASHI Takahiro 2015-07-13 5:29 ` [RFC 3/3] arm64: ftrace: mcount() should not create a stack frame AKASHI Takahiro 2015-07-13 5:29 ` AKASHI Takahiro 2015-07-13 15:01 ` [RFC 0/3] arm64: ftrace: fix incorrect output from stack tracer Jungseok Lee 2015-07-13 15:01 ` Jungseok Lee
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=1436765375-7119-1-git-send-email-takahiro.akashi@linaro.org \ --to=takahiro.akashi@linaro.org \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=david.griego@linaro.org \ --cc=jungseoklee85@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=olof@lixom.net \ --cc=rostedt@goodmis.org \ --cc=will.deacon@arm.com \ /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: linkBe 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.