| Message ID | 163369611948.636038.11552166777773804729.stgit@devnote2 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | kprobes: Make KUnit and add stacktrace on kretprobe tests | expand |
On Fri, Oct 08, 2021 at 09:28:39PM +0900, Masami Hiramatsu wrote: > Record the frame pointer instead of stack address with kretprobe > instance as the identifier on the instance list. > Since arm64 always enable CONFIG_FRAME_POINTER, we can use the > actual frame pointer (x29). > > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> > --- > arch/arm64/kernel/probes/kprobes.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c > index e7ad6da980e8..d9dfa82c1f18 100644 > --- a/arch/arm64/kernel/probes/kprobes.c > +++ b/arch/arm64/kernel/probes/kprobes.c > @@ -401,14 +401,14 @@ int __init arch_populate_kprobe_blacklist(void) > > void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs) > { > - return (void *)kretprobe_trampoline_handler(regs, (void *)kernel_stack_pointer(regs)); > + return (void *)kretprobe_trampoline_handler(regs, (void *)regs->regs[29]); > } > > void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri, > struct pt_regs *regs) > { > ri->ret_addr = (kprobe_opcode_t *)regs->regs[30]; > - ri->fp = (void *)kernel_stack_pointer(regs); > + ri->fp = (void *)regs->regs[29]; > > /* replace return addr (x30) with trampoline */ > regs->regs[30] = (long)&__kretprobe_trampoline; Acked-by: Will Deacon <will@kernel.org> Will
On Fri, Oct 08, 2021 at 09:28:39PM +0900, Masami Hiramatsu wrote: > Record the frame pointer instead of stack address with kretprobe > instance as the identifier on the instance list. > Since arm64 always enable CONFIG_FRAME_POINTER, we can use the > actual frame pointer (x29). Just to check, why do we need to use the FP rather than SP? It wasn't clear to me if that's necessary later in the series, or if I'm missing something here. FWIW, I plan to rework arm64's ftrace bits to use FP for HAVE_FUNCTION_GRAPH_RET_ADDR_PTR, so I'm happy to do likewise here. > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Regardless of the above: Acked-by: Mark Rutland <mark.rutland@arm.com> Mark. > --- > arch/arm64/kernel/probes/kprobes.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c > index e7ad6da980e8..d9dfa82c1f18 100644 > --- a/arch/arm64/kernel/probes/kprobes.c > +++ b/arch/arm64/kernel/probes/kprobes.c > @@ -401,14 +401,14 @@ int __init arch_populate_kprobe_blacklist(void) > > void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs) > { > - return (void *)kretprobe_trampoline_handler(regs, (void *)kernel_stack_pointer(regs)); > + return (void *)kretprobe_trampoline_handler(regs, (void *)regs->regs[29]); > } > > void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri, > struct pt_regs *regs) > { > ri->ret_addr = (kprobe_opcode_t *)regs->regs[30]; > - ri->fp = (void *)kernel_stack_pointer(regs); > + ri->fp = (void *)regs->regs[29]; > > /* replace return addr (x30) with trampoline */ > regs->regs[30] = (long)&__kretprobe_trampoline; >
On Wed, 13 Oct 2021 11:01:39 +0100 Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Oct 08, 2021 at 09:28:39PM +0900, Masami Hiramatsu wrote: > > Record the frame pointer instead of stack address with kretprobe > > instance as the identifier on the instance list. > > Since arm64 always enable CONFIG_FRAME_POINTER, we can use the > > actual frame pointer (x29). > > Just to check, why do we need to use the FP rather than SP? It wasn't > clear to me if that's necessary later in the series, or if I'm missing > something here. Actually, this is for finding correct return address from the per-task kretprobe instruction list (suppose it as a shadow stack) when it will be searched in stack-backtracing. At that point, the framepointer will be a reliable key. > > FWIW, I plan to rework arm64's ftrace bits to use FP for > HAVE_FUNCTION_GRAPH_RET_ADDR_PTR, so I'm happy to do likewise here. Yes, I think you can use FP for that too. > > > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> > > Regardless of the above: > > Acked-by: Mark Rutland <mark.rutland@arm.com> Thank you! > > Mark. > > > --- > > arch/arm64/kernel/probes/kprobes.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c > > index e7ad6da980e8..d9dfa82c1f18 100644 > > --- a/arch/arm64/kernel/probes/kprobes.c > > +++ b/arch/arm64/kernel/probes/kprobes.c > > @@ -401,14 +401,14 @@ int __init arch_populate_kprobe_blacklist(void) > > > > void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs) > > { > > - return (void *)kretprobe_trampoline_handler(regs, (void *)kernel_stack_pointer(regs)); > > + return (void *)kretprobe_trampoline_handler(regs, (void *)regs->regs[29]); > > } > > > > void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri, > > struct pt_regs *regs) > > { > > ri->ret_addr = (kprobe_opcode_t *)regs->regs[30]; > > - ri->fp = (void *)kernel_stack_pointer(regs); > > + ri->fp = (void *)regs->regs[29]; > > > > /* replace return addr (x30) with trampoline */ > > regs->regs[30] = (long)&__kretprobe_trampoline; > >
On Thu, Oct 14, 2021 at 05:04:05PM +0900, Masami Hiramatsu wrote: > On Wed, 13 Oct 2021 11:01:39 +0100 > Mark Rutland <mark.rutland@arm.com> wrote: > > > On Fri, Oct 08, 2021 at 09:28:39PM +0900, Masami Hiramatsu wrote: > > > Record the frame pointer instead of stack address with kretprobe > > > instance as the identifier on the instance list. > > > Since arm64 always enable CONFIG_FRAME_POINTER, we can use the > > > actual frame pointer (x29). > > > > Just to check, why do we need to use the FP rather than SP? It wasn't > > clear to me if that's necessary later in the series, or if I'm missing > > something here. > > Actually, this is for finding correct return address from the per-task > kretprobe instruction list (suppose it as a shadow stack) when it will > be searched in stack-backtracing. At that point, the framepointer will > be a reliable key. Sure, my question was more "why isn't the SP a reliable key?", because both the SP and FP should be balanced at function-entry and function-return time. I'm asking because I think I'm missing a subtlety. I'm perfectly happy to use the FP even if they're equivalent; I just want to make sure there's not some issue I'm unaware of that could affect unwinding. Thanks, Mark. > > FWIW, I plan to rework arm64's ftrace bits to use FP for > > HAVE_FUNCTION_GRAPH_RET_ADDR_PTR, so I'm happy to do likewise here. > > Yes, I think you can use FP for that too. > > > > > > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> > > > > Regardless of the above: > > > > Acked-by: Mark Rutland <mark.rutland@arm.com> > > Thank you! > > > > > Mark. > > > > > --- > > > arch/arm64/kernel/probes/kprobes.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c > > > index e7ad6da980e8..d9dfa82c1f18 100644 > > > --- a/arch/arm64/kernel/probes/kprobes.c > > > +++ b/arch/arm64/kernel/probes/kprobes.c > > > @@ -401,14 +401,14 @@ int __init arch_populate_kprobe_blacklist(void) > > > > > > void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs) > > > { > > > - return (void *)kretprobe_trampoline_handler(regs, (void *)kernel_stack_pointer(regs)); > > > + return (void *)kretprobe_trampoline_handler(regs, (void *)regs->regs[29]); > > > } > > > > > > void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri, > > > struct pt_regs *regs) > > > { > > > ri->ret_addr = (kprobe_opcode_t *)regs->regs[30]; > > > - ri->fp = (void *)kernel_stack_pointer(regs); > > > + ri->fp = (void *)regs->regs[29]; > > > > > > /* replace return addr (x30) with trampoline */ > > > regs->regs[30] = (long)&__kretprobe_trampoline; > > > > > > -- > Masami Hiramatsu <mhiramat@kernel.org>
On Thu, 14 Oct 2021 10:13:32 +0100 Mark Rutland <mark.rutland@arm.com> wrote: > On Thu, Oct 14, 2021 at 05:04:05PM +0900, Masami Hiramatsu wrote: > > On Wed, 13 Oct 2021 11:01:39 +0100 > > Mark Rutland <mark.rutland@arm.com> wrote: > > > > > On Fri, Oct 08, 2021 at 09:28:39PM +0900, Masami Hiramatsu wrote: > > > > Record the frame pointer instead of stack address with kretprobe > > > > instance as the identifier on the instance list. > > > > Since arm64 always enable CONFIG_FRAME_POINTER, we can use the > > > > actual frame pointer (x29). > > > > > > Just to check, why do we need to use the FP rather than SP? It wasn't > > > clear to me if that's necessary later in the series, or if I'm missing > > > something here. > > > > Actually, this is for finding correct return address from the per-task > > kretprobe instruction list (suppose it as a shadow stack) when it will > > be searched in stack-backtracing. At that point, the framepointer will > > be a reliable key. > > Sure, my question was more "why isn't the SP a reliable key?", because both > the SP and FP should be balanced at function-entry and function-return > time. I'm asking because I think I'm missing a subtlety. Ah, because SP is not used while unwinding frame. For the kretprobe, either FP or SP is OK. But for the stacktrace.c, I can not use SP and is easy to change to use FP. :) So, when we introduce ORC unwinder on arm64, I think I have to reconsider using SP based on the configuration. Thank you, > > I'm perfectly happy to use the FP even if they're equivalent; I just > want to make sure there's not some issue I'm unaware of that could > affect unwinding. > > Thanks, > Mark. > > > > FWIW, I plan to rework arm64's ftrace bits to use FP for > > > HAVE_FUNCTION_GRAPH_RET_ADDR_PTR, so I'm happy to do likewise here. > > > > Yes, I think you can use FP for that too. > > > > > > > > > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> > > > > > > Regardless of the above: > > > > > > Acked-by: Mark Rutland <mark.rutland@arm.com> > > > > Thank you! > > > > > > > > Mark. > > > > > > > --- > > > > arch/arm64/kernel/probes/kprobes.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c > > > > index e7ad6da980e8..d9dfa82c1f18 100644 > > > > --- a/arch/arm64/kernel/probes/kprobes.c > > > > +++ b/arch/arm64/kernel/probes/kprobes.c > > > > @@ -401,14 +401,14 @@ int __init arch_populate_kprobe_blacklist(void) > > > > > > > > void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs) > > > > { > > > > - return (void *)kretprobe_trampoline_handler(regs, (void *)kernel_stack_pointer(regs)); > > > > + return (void *)kretprobe_trampoline_handler(regs, (void *)regs->regs[29]); > > > > } > > > > > > > > void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri, > > > > struct pt_regs *regs) > > > > { > > > > ri->ret_addr = (kprobe_opcode_t *)regs->regs[30]; > > > > - ri->fp = (void *)kernel_stack_pointer(regs); > > > > + ri->fp = (void *)regs->regs[29]; > > > > > > > > /* replace return addr (x30) with trampoline */ > > > > regs->regs[30] = (long)&__kretprobe_trampoline; > > > > > > > > > > -- > > Masami Hiramatsu <mhiramat@kernel.org>
On Thu, Oct 14, 2021 at 07:01:55PM +0900, Masami Hiramatsu wrote: > On Thu, 14 Oct 2021 10:13:32 +0100 > Mark Rutland <mark.rutland@arm.com> wrote: > > > On Thu, Oct 14, 2021 at 05:04:05PM +0900, Masami Hiramatsu wrote: > > > On Wed, 13 Oct 2021 11:01:39 +0100 > > > Mark Rutland <mark.rutland@arm.com> wrote: > > > > > > > On Fri, Oct 08, 2021 at 09:28:39PM +0900, Masami Hiramatsu wrote: > > > > > Record the frame pointer instead of stack address with kretprobe > > > > > instance as the identifier on the instance list. > > > > > Since arm64 always enable CONFIG_FRAME_POINTER, we can use the > > > > > actual frame pointer (x29). > > > > > > > > Just to check, why do we need to use the FP rather than SP? It wasn't > > > > clear to me if that's necessary later in the series, or if I'm missing > > > > something here. > > > > > > Actually, this is for finding correct return address from the per-task > > > kretprobe instruction list (suppose it as a shadow stack) when it will > > > be searched in stack-backtracing. At that point, the framepointer will > > > be a reliable key. > > > > Sure, my question was more "why isn't the SP a reliable key?", because both > > the SP and FP should be balanced at function-entry and function-return > > time. I'm asking because I think I'm missing a subtlety. > > Ah, because SP is not used while unwinding frame. For the kretprobe, > either FP or SP is OK. But for the stacktrace.c, I can not use SP > and is easy to change to use FP. :) Ah, so this is just so that stacktrace can match the address. For clarity, would you be happy to add a sentence to the commit message like: | This will allow the stacktrace code to find the original return | address from the FP alone. Thanks, Mark.
On Thu, 14 Oct 2021 11:27:02 +0100 Mark Rutland <mark.rutland@arm.com> wrote: > On Thu, Oct 14, 2021 at 07:01:55PM +0900, Masami Hiramatsu wrote: > > On Thu, 14 Oct 2021 10:13:32 +0100 > > Mark Rutland <mark.rutland@arm.com> wrote: > > > > > On Thu, Oct 14, 2021 at 05:04:05PM +0900, Masami Hiramatsu wrote: > > > > On Wed, 13 Oct 2021 11:01:39 +0100 > > > > Mark Rutland <mark.rutland@arm.com> wrote: > > > > > > > > > On Fri, Oct 08, 2021 at 09:28:39PM +0900, Masami Hiramatsu wrote: > > > > > > Record the frame pointer instead of stack address with kretprobe > > > > > > instance as the identifier on the instance list. > > > > > > Since arm64 always enable CONFIG_FRAME_POINTER, we can use the > > > > > > actual frame pointer (x29). > > > > > > > > > > Just to check, why do we need to use the FP rather than SP? It wasn't > > > > > clear to me if that's necessary later in the series, or if I'm missing > > > > > something here. > > > > > > > > Actually, this is for finding correct return address from the per-task > > > > kretprobe instruction list (suppose it as a shadow stack) when it will > > > > be searched in stack-backtracing. At that point, the framepointer will > > > > be a reliable key. > > > > > > Sure, my question was more "why isn't the SP a reliable key?", because both > > > the SP and FP should be balanced at function-entry and function-return > > > time. I'm asking because I think I'm missing a subtlety. > > > > Ah, because SP is not used while unwinding frame. For the kretprobe, > > either FP or SP is OK. But for the stacktrace.c, I can not use SP > > and is easy to change to use FP. :) > > Ah, so this is just so that stacktrace can match the address. For > clarity, would you be happy to add a sentence to the commit message like: > > | This will allow the stacktrace code to find the original return > | address from the FP alone. Yes, I'm happy to update the changelog :) Thanks! > > Thanks, > Mark.
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c index e7ad6da980e8..d9dfa82c1f18 100644 --- a/arch/arm64/kernel/probes/kprobes.c +++ b/arch/arm64/kernel/probes/kprobes.c @@ -401,14 +401,14 @@ int __init arch_populate_kprobe_blacklist(void) void __kprobes __used *trampoline_probe_handler(struct pt_regs *regs) { - return (void *)kretprobe_trampoline_handler(regs, (void *)kernel_stack_pointer(regs)); + return (void *)kretprobe_trampoline_handler(regs, (void *)regs->regs[29]); } void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri, struct pt_regs *regs) { ri->ret_addr = (kprobe_opcode_t *)regs->regs[30]; - ri->fp = (void *)kernel_stack_pointer(regs); + ri->fp = (void *)regs->regs[29]; /* replace return addr (x30) with trampoline */ regs->regs[30] = (long)&__kretprobe_trampoline;
Record the frame pointer instead of stack address with kretprobe instance as the identifier on the instance list. Since arm64 always enable CONFIG_FRAME_POINTER, we can use the actual frame pointer (x29). Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> --- arch/arm64/kernel/probes/kprobes.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)