On 2018-11-11, Masami Hiramatsu wrote:
> > > > + addr = kretprobe_ret_addr(current, addr,
> > > > stack_addr(regs));
> > >
> > > But since kretprobe will be an event, which can kick the stackdump.
> > > BTW, from kretprobe, regs->ip should always be the trampoline handler,
> > > s
On Sat, 10 Nov 2018 02:06:29 +1100
Aleksa Sarai wrote:
> On 2018-11-09, Masami Hiramatsu wrote:
> > > diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
> > > index ee696efec99f..c4dfafd43e11 100644
> > > --- a/arch/x86/include/asm/ptrace.h
> > > +++ b/arch/x86/include/as
On 2018-11-09, Masami Hiramatsu wrote:
> On Thu, 8 Nov 2018 08:44:37 -0600
> Josh Poimboeuf wrote:
>
> > On Thu, Nov 08, 2018 at 07:04:48PM +1100, Aleksa Sarai wrote:
> > > On 2018-11-08, Aleksa Sarai wrote:
> > > > I will attach what I have at the moment to hopefully explain what the
> > > > i
On 2018-11-09, Masami Hiramatsu wrote:
> > diff --git a/arch/x86/include/asm/ptrace.h b/arch/x86/include/asm/ptrace.h
> > index ee696efec99f..c4dfafd43e11 100644
> > --- a/arch/x86/include/asm/ptrace.h
> > +++ b/arch/x86/include/asm/ptrace.h
> > @@ -172,6 +172,7 @@ static inline unsigned long kern
On Thu, 8 Nov 2018 08:44:37 -0600
Josh Poimboeuf wrote:
> On Thu, Nov 08, 2018 at 07:04:48PM +1100, Aleksa Sarai wrote:
> > On 2018-11-08, Aleksa Sarai wrote:
> > > I will attach what I have at the moment to hopefully explain what the
> > > issue I've found is (re-using the kretprobe architectur
On Thu, 8 Nov 2018 19:04:48 +1100
Aleksa Sarai wrote:
> On 2018-11-08, Aleksa Sarai wrote:
> > I will attach what I have at the moment to hopefully explain what the
> > issue I've found is (re-using the kretprobe architecture but with the
> > shadow-stack idea).
>
> Here is the patch I have at
On Thu, Nov 08, 2018 at 07:04:48PM +1100, Aleksa Sarai wrote:
> On 2018-11-08, Aleksa Sarai wrote:
> > I will attach what I have at the moment to hopefully explain what the
> > issue I've found is (re-using the kretprobe architecture but with the
> > shadow-stack idea).
>
> Here is the patch I ha
On 2018-11-08, Aleksa Sarai wrote:
> I will attach what I have at the moment to hopefully explain what the
> issue I've found is (re-using the kretprobe architecture but with the
> shadow-stack idea).
Here is the patch I have at the moment (it works, except for the
question I have about how to ha
On 2018-11-06, Steven Rostedt wrote:
> On Sun, 4 Nov 2018 22:59:13 +1100
> Aleksa Sarai wrote:
>
> > The same issue is present in __save_stack_trace
> > (arch/x86/kernel/stacktrace.c). This is likely the only reason that --
> > as Steven said -- stacktraces wouldn't work with ftrace-graph (and t
On Sun, 4 Nov 2018 22:59:13 +1100
Aleksa Sarai wrote:
> The same issue is present in __save_stack_trace
> (arch/x86/kernel/stacktrace.c). This is likely the only reason that --
> as Steven said -- stacktraces wouldn't work with ftrace-graph (and thus
> with the refactor both of you are discussing
On 2018-11-03, Aleksa Sarai wrote:
> This is actually a general bug in ftrace as well, because (for
> instance) while the unwinder calls into ftrace_graph_ret_addr() while
> walking up the stack this isn't used to correct regs->ip in
> perf_callchain_kernel(). I think this is the cause of the bug
On Sat, 3 Nov 2018 13:30:21 -0400
Steven Rostedt wrote:
> On Sun, 4 Nov 2018 01:34:30 +0900
> Masami Hiramatsu wrote:
> >
> > > I was thinking of a bitmask that represents the handlers, and use that
> > > to map which handler gets called for which shadow entry for a
> > > particular task.
> >
On Sat, 3 Nov 2018 13:30:21 -0400
Steven Rostedt wrote:
> What I was thinking was to store a count and the functions to be called:
>
>
> [original_return_address]
> [function_A]
> [function_B]
> [function_C]
> [ 3 ]
>
> Then the trampoline that processes the retur
On Sun, 4 Nov 2018 01:34:30 +0900
Masami Hiramatsu wrote:
>
> > I was thinking of a bitmask that represents the handlers, and use that
> > to map which handler gets called for which shadow entry for a
> > particular task.
>
> Hmm, I doubt that is too complicated and not scalable. I rather like
On Sat, 3 Nov 2018 09:13:41 -0400
Steven Rostedt wrote:
> On Sat, 3 Nov 2018 22:00:12 +0900
> Masami Hiramatsu wrote:
>
> > On Fri, 2 Nov 2018 12:13:07 -0400
> > Steven Rostedt wrote:
> >
>
> > > Because that means if function graph tracer is active, then you can't
> > > do a kretprobe, and
On Fri, 2 Nov 2018 09:16:58 -0400
Steven Rostedt wrote:
> On Fri, 2 Nov 2018 17:59:32 +1100
> Aleksa Sarai wrote:
>
> > As an aside, I just tested with the frame unwinder and it isn't thrown
> > off-course by kretprobe_trampoline (though obviously the stack is still
> > wrong). So I think we ju
On Sat, 3 Nov 2018 22:00:12 +0900
Masami Hiramatsu wrote:
> On Fri, 2 Nov 2018 12:13:07 -0400
> Steven Rostedt wrote:
>
> > Because that means if function graph tracer is active, then you can't
> > do a kretprobe, and vice versa. I'd really like to have it working for
> > multiple users, then
On Fri, 2 Nov 2018 12:13:07 -0400
Steven Rostedt wrote:
> On Fri, 2 Nov 2018 10:43:26 -0500
> Josh Poimboeuf wrote:
>
> > > I'll hopefully have a prototype ready by plumbers.
> >
> > Why do we need multiple users? It would be a lot simpler if we could
> > just enforce a single user per fgra
On Fri, 2 Nov 2018 15:37:33 +1100
Aleksa Sarai wrote:
> On 2018-11-02, Masami Hiramatsu wrote:
> > On Fri, 2 Nov 2018 08:13:43 +1100
> > Aleksa Sarai wrote:
> >
> > > On 2018-11-02, Masami Hiramatsu wrote:
> > > > Please split the test case as an independent patch.
> > >
> > > Will do. Shoul
On 2018-11-02, Steven Rostedt wrote:
> > As an aside, I just tested with the frame unwinder and it isn't thrown
> > off-course by kretprobe_trampoline (though obviously the stack is still
> > wrong). So I think we just need to hook into the ORC unwinder to get it
> > to continue skipping up the st
On Fri, 2 Nov 2018 10:43:26 -0500
Josh Poimboeuf wrote:
> > I'll hopefully have a prototype ready by plumbers.
>
> Why do we need multiple users? It would be a lot simpler if we could
> just enforce a single user per fgraphed/kretprobed function (and return
> -EBUSY if it's already being trac
On Fri, Nov 02, 2018 at 09:16:58AM -0400, Steven Rostedt wrote:
> On Fri, 2 Nov 2018 17:59:32 +1100
> Aleksa Sarai wrote:
>
> > As an aside, I just tested with the frame unwinder and it isn't thrown
> > off-course by kretprobe_trampoline (though obviously the stack is still
> > wrong). So I think
On Fri, 2 Nov 2018 17:59:32 +1100
Aleksa Sarai wrote:
> As an aside, I just tested with the frame unwinder and it isn't thrown
> off-course by kretprobe_trampoline (though obviously the stack is still
> wrong). So I think we just need to hook into the ORC unwinder to get it
> to continue skipping
On 2018-11-02, Aleksa Sarai wrote:
> Unfortunately, I'm having a lot of trouble understanding how the current
> ftrace hooking works -- ORC has a couple of ftrace hooks that seem
> reasonable on the surface but I don't understand (for instance) how
> HAVE_FUNCTION_GRAPH_RET_ADDR_PTR *actually* wor
On 2018-11-02, Aleksa Sarai wrote:
> For kretprobes I think it would be fairly easy to reconstruct what
> landed you into a kretprobe_trampoline by walking the set of
> kretprobe_instances (since all new ones are added to the head, you can
> get the real return address in-order).
>
> But I still
On 2018-11-01, Steven Rostedt wrote:
> On Thu, 1 Nov 2018 19:35:50 +1100
> Aleksa Sarai wrote:
> > @@ -1834,6 +1853,11 @@ static int pre_handler_kretprobe(struct kprobe *p,
> > struct pt_regs *regs)
> > ri->rp = rp;
> > ri->task = current;
> >
> > + trace.ent
On 2018-11-02, Masami Hiramatsu wrote:
> On Fri, 2 Nov 2018 08:13:43 +1100
> Aleksa Sarai wrote:
>
> > On 2018-11-02, Masami Hiramatsu wrote:
> > > Please split the test case as an independent patch.
> >
> > Will do. Should the Documentation/ change also be a separate patch?
>
> I think the D
Hi Aleksa,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.19 next-20181101]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/comm
On Fri, 2 Nov 2018 08:13:43 +1100
Aleksa Sarai wrote:
> On 2018-11-02, Masami Hiramatsu wrote:
> > Please split the test case as an independent patch.
>
> Will do. Should the Documentation/ change also be a separate patch?
I think the Documentation change can be coupled with code change
if the
On Thu, 1 Nov 2018 19:35:50 +1100
Aleksa Sarai wrote:
> Historically, kretprobe has always produced unusable stack traces
> (kretprobe_trampoline is the only entry in most cases, because of the
> funky stack pointer overwriting). This has caused quite a few annoyances
> when using tracing to deb
On 2018-11-02, Masami Hiramatsu wrote:
> Please split the test case as an independent patch.
Will do. Should the Documentation/ change also be a separate patch?
> > new file mode 100644
> > index ..03146c6a1a3c
> > --- /dev/null
> > +++ b/tools/testing/selftests/ftrace/test.d/kprobe/
Hi Aleksa,
On Thu, 1 Nov 2018 19:35:50 +1100
Aleksa Sarai wrote:
[...]
> diff --git
> a/tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_stacktrace.tc
> b/tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_stacktrace.tc
Please split the test case as an independent patch.
> new file
Historically, kretprobe has always produced unusable stack traces
(kretprobe_trampoline is the only entry in most cases, because of the
funky stack pointer overwriting). This has caused quite a few annoyances
when using tracing to debug problems[1] -- since return values are only
available with kre
33 matches
Mail list logo
