Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1452611 > unrolled thread
| Started by | Steven Rostedt <rostedt@goodmis.org> |
|---|---|
| First post | 2016-07-30 01:00 +0200 |
| Last post | 2016-08-01 18:50 +0200 |
| Articles | 6 on this page of 26 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Steven Rostedt <rostedt@goodmis.org> - 2016-07-30 01:00 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-30 03:00 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Steven Rostedt <rostedt@goodmis.org> - 2016-07-30 04:30 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-30 16:00 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Steven Rostedt <rostedt@goodmis.org> - 2016-08-01 16:30 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-08-01 17:40 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-08-02 23:10 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Steven Rostedt <rostedt@goodmis.org> - 2016-08-02 23:20 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-08-03 00:20 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Steven Rostedt <rostedt@goodmis.org> - 2016-08-03 01:20 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-08-03 04:10 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Steven Rostedt <rostedt@goodmis.org> - 2016-08-03 04:40 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-08-03 05:00 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Steven Rostedt <rostedt@goodmis.org> - 2016-08-03 05:10 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-08-03 05:20 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Steven Rostedt <rostedt@goodmis.org> - 2016-08-03 05:30 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-08-03 05:40 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Steven Rostedt <rostedt@goodmis.org> - 2016-08-03 05:50 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-08-03 16:30 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Steven Rostedt <rostedt@goodmis.org> - 2016-08-03 05:40 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-08-03 05:40 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-08-01 18:20 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Steven Rostedt <rostedt@goodmis.org> - 2016-08-01 18:20 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-08-01 18:40 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Steven Rostedt <rostedt@goodmis.org> - 2016-08-01 19:00 +0200
Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues Josh Poimboeuf <jpoimboe@redhat.com> - 2016-08-01 18:50 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | Josh Poimboeuf <jpoimboe@redhat.com> |
|---|---|
| Date | 2016-08-03 05:40 +0200 |
| Message-ID | <s1Vce-5jd-11@gated-at.bofh.it> |
| In reply to | #1455611 |
On Tue, Aug 02, 2016 at 11:18:57PM -0400, Steven Rostedt wrote: > On Tue, 2 Aug 2016 22:12:33 -0500 > Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > > Sounds good. I was thinking I could also add a similar define to > > indicate whether an arch passes the return address stack pointer to > > ftrace_push_return_trace(). HAVE_FUNCTION_GRAPH_RET_ADDR_PTR? > > > > If you are making this function global, might as well make all pass > that pointer when you do the conversion. I don't think we need a define > to differentiate it. In theory, I like the idea. But from what I can tell, it looks like a few arches would require some assembly changes: s390, powerpc, and sparc. I can probably handle s390 and power, but sparc is a whole different story... -- Josh
[toc] | [prev] | [next] | [standalone]
| From | Josh Poimboeuf <jpoimboe@redhat.com> |
|---|---|
| Date | 2016-08-01 18:20 +0200 |
| Message-ID | <s1o6B-bJ-7@gated-at.bofh.it> |
| In reply to | #1452611 |
On Mon, Aug 01, 2016 at 12:05:41PM -0400, Steven Rostedt wrote:
> On Mon, 1 Aug 2016 10:59:03 -0500
> Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> > On Fri, Jul 29, 2016 at 06:55:21PM -0400, Steven Rostedt wrote:
> > > Here's my patch that should be applied on top.
> > >
> > > Maybe add a Signed-off-by: Steven Rostedt <rostedt@goodmis.org> along
> > > with your SOB. But you should remain Author.
> >
> > [...]
> >
> > > @@ -123,13 +124,16 @@ print_context_stack_bp(struct task_struc
> > >
> > > while (valid_stack_ptr(task, ret_addr, sizeof(*ret_addr), end)) {
> > > unsigned long addr = *ret_addr;
> > > + unsigned long real_addr;
> > >
> > > if (!__kernel_text_address(addr))
> > > break;
> > >
> > > - addr = ftrace_graph_ret_addr(task, graph, addr);
> > > - if (ops->address(data, addr, 1))
> > > + real_addr = ftrace_graph_ret_addr(task, graph, addr);
> > > + if (ops->address(data, real_addr, 1))
> > > break;
> > > + if (real_addr != addr)
> > > + ops->address(data, addr, 0);
> > > frame = frame->next_frame;
> > > ret_addr = &frame->return_address;
> > > }
> >
> > Actually this hunk isn't needed because all users of
> > print_context_stack_bp() only care about "reliable" addresses. With
> > frame pointers enabled, the only place "unreliable" addresses are used
> > is in show_trace_log_lvl() -- and it uses the print_context_stack()
> > callback.
> >
> > I rely on that fact in the new frame pointer unwind code: it only
> > reports reliable addresses.
> >
>
> Can you make this a separate patch then. Before this one, and explain
> why it isn't needed in the change log. I rather have the current patch
> not make such a change in logic.
Sure, I'll do that.
--
Josh
[toc] | [prev] | [next] | [standalone]
| From | Steven Rostedt <rostedt@goodmis.org> |
|---|---|
| Date | 2016-08-01 18:20 +0200 |
| Message-ID | <s1o6B-bJ-11@gated-at.bofh.it> |
| In reply to | #1452611 |
On Mon, 1 Aug 2016 10:59:03 -0500
Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> On Fri, Jul 29, 2016 at 06:55:21PM -0400, Steven Rostedt wrote:
> > Here's my patch that should be applied on top.
> >
> > Maybe add a Signed-off-by: Steven Rostedt <rostedt@goodmis.org> along
> > with your SOB. But you should remain Author.
>
> [...]
>
> > @@ -123,13 +124,16 @@ print_context_stack_bp(struct task_struc
> >
> > while (valid_stack_ptr(task, ret_addr, sizeof(*ret_addr), end)) {
> > unsigned long addr = *ret_addr;
> > + unsigned long real_addr;
> >
> > if (!__kernel_text_address(addr))
> > break;
> >
> > - addr = ftrace_graph_ret_addr(task, graph, addr);
> > - if (ops->address(data, addr, 1))
> > + real_addr = ftrace_graph_ret_addr(task, graph, addr);
> > + if (ops->address(data, real_addr, 1))
> > break;
> > + if (real_addr != addr)
> > + ops->address(data, addr, 0);
> > frame = frame->next_frame;
> > ret_addr = &frame->return_address;
> > }
>
> Actually this hunk isn't needed because all users of
> print_context_stack_bp() only care about "reliable" addresses. With
> frame pointers enabled, the only place "unreliable" addresses are used
> is in show_trace_log_lvl() -- and it uses the print_context_stack()
> callback.
>
> I rely on that fact in the new frame pointer unwind code: it only
> reports reliable addresses.
>
Can you make this a separate patch then. Before this one, and explain
why it isn't needed in the change log. I rather have the current patch
not make such a change in logic.
-- Steve
[toc] | [prev] | [next] | [standalone]
| From | Josh Poimboeuf <jpoimboe@redhat.com> |
|---|---|
| Date | 2016-08-01 18:40 +0200 |
| Message-ID | <s1opY-ih-45@gated-at.bofh.it> |
| In reply to | #1452611 |
On Fri, Jul 29, 2016 at 06:55:21PM -0400, Steven Rostedt wrote:
> > @@ -108,18 +97,23 @@ print_context_stack(struct task_struct *task,
> > stack = (unsigned long *)task_stack_page(task);
> >
> > while (valid_stack_ptr(task, stack, sizeof(*stack), end)) {
> > - unsigned long addr;
> > + unsigned long addr = *stack;
> >
> > addr = *stack;
> > if (__kernel_text_address(addr)) {
> > + int reliable = 0;
> > + unsigned long real_addr;
> > +
> > if ((unsigned long) stack == bp + sizeof(long)) {
> > - ops->address(data, addr, 1);
> > + reliable = 1;
> > frame = frame->next_frame;
> > bp = (unsigned long) frame;
> > - } else {
> > - ops->address(data, addr, 0);
> > }
> > - print_ftrace_graph_addr(addr, data, ops, task, graph);
> > +
> > + real_addr = ftrace_graph_ret_addr(task, graph, addr);
> > + if (addr != real_addr)
> > + ops->address(data, addr, 0);
> > + ops->address(data, real_addr, reliable);
>
> Note this changes behavior, as the original code had the ret_to_handler
> first. This makes it second. (I fixed this below).
Hm, as far as I can tell this actually keeps the original behavior. The
"unreliable" ret_to_handler is still printed first, no?
--
Josh
[toc] | [prev] | [next] | [standalone]
| From | Steven Rostedt <rostedt@goodmis.org> |
|---|---|
| Date | 2016-08-01 19:00 +0200 |
| Message-ID | <s1oJk-pz-25@gated-at.bofh.it> |
| In reply to | #1453309 |
On Mon, 1 Aug 2016 11:24:59 -0500 Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > > - print_ftrace_graph_addr(addr, data, ops, task, graph); > > > + > > > + real_addr = ftrace_graph_ret_addr(task, graph, addr); > > > + if (addr != real_addr) > > > + ops->address(data, addr, 0); > > > + ops->address(data, real_addr, reliable); > > > > Note this changes behavior, as the original code had the ret_to_handler > > first. This makes it second. (I fixed this below). > > Hm, as far as I can tell this actually keeps the original behavior. The > "unreliable" ret_to_handler is still printed first, no? > Yep, I guess it does. I mixed up the meaning of "real_addr" and "addr", and was thinking of the reverse. -- Steve
[toc] | [prev] | [next] | [standalone]
| From | Josh Poimboeuf <jpoimboe@redhat.com> |
|---|---|
| Date | 2016-08-01 18:50 +0200 |
| Message-ID | <s1o6B-bJ-9@gated-at.bofh.it> |
| In reply to | #1452611 |
On Fri, Jul 29, 2016 at 06:55:21PM -0400, Steven Rostedt wrote:
> Here's my patch that should be applied on top.
>
> Maybe add a Signed-off-by: Steven Rostedt <rostedt@goodmis.org> along
> with your SOB. But you should remain Author.
[...]
> @@ -123,13 +124,16 @@ print_context_stack_bp(struct task_struc
>
> while (valid_stack_ptr(task, ret_addr, sizeof(*ret_addr), end)) {
> unsigned long addr = *ret_addr;
> + unsigned long real_addr;
>
> if (!__kernel_text_address(addr))
> break;
>
> - addr = ftrace_graph_ret_addr(task, graph, addr);
> - if (ops->address(data, addr, 1))
> + real_addr = ftrace_graph_ret_addr(task, graph, addr);
> + if (ops->address(data, real_addr, 1))
> break;
> + if (real_addr != addr)
> + ops->address(data, addr, 0);
> frame = frame->next_frame;
> ret_addr = &frame->return_address;
> }
Actually this hunk isn't needed because all users of
print_context_stack_bp() only care about "reliable" addresses. With
frame pointers enabled, the only place "unreliable" addresses are used
is in show_trace_log_lvl() -- and it uses the print_context_stack()
callback.
I rely on that fact in the new frame pointer unwind code: it only
reports reliable addresses.
--
Josh
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web