mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Jason Baron <jbaron@redhat.com>,
	yrl.pp-manager.tt@hitachi.com
Subject: Re: [PATCH 3/5][RFC] ftrace: Return pt_regs to function trace callback (x86_64 only so
Date: Thu, 11 Aug 2011 08:59:26 -0400	[thread overview]
Message-ID: <1313067566.18583.288.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <4E436EDC.2080101@hitachi.com>

On Thu, 2011-08-11 at 14:55 +0900, Masami Hiramatsu wrote:
> (2011/08/11 1:22), Steven Rostedt wrote:
> > From: Steven Rostedt <srostedt@redhat.com>
> >
> > Return as the 4th paramater to the function tracer callback the pt_regs.
> >
> > So far this is only supported by x86_64. The ftrace_ops flag
> > FTRACE_OPS_FL_SAVE_REGS is added to tell the arch to save all regs
> > to the pt_regs, otherwise a minimum is just passed back (the same
> > regs that is saved by mcount itself).
> 
> I guess it will be a bit hard to port this on x86-32, because
> on x86-32, the top of stack address in pt_regs is the address
> of sp member (e.g. &(pt_regs->sp)). I mean that when mcount-entry
> calls ftrace_caller, it pushes an address of the next instruction
> of mcount-entry on the top of stack.
> In that case, &(pt_regs->sp) points the entry which stores the
> address, instead of the return address of probed function.

I'm a little confused here. What is needed by kprobes handlers?

It should be no problem saving the sp member onto pt_regs of the time
mcount was called, and simulate the probe as if it was put on the nop.

> 
> e.g. with kprobes (on x86-32):
> 
> [  <bx>  ] <- pt_regs
> [  ...   ]
> [  <cs>  ]
> [<flags> ]
> [ret-addr] <- &(pt_regs.sp)
> [  arg1  ]
> [  arg2  ]
> 
> with this method:
> 
> [  <bx>  ] <- pt_regs
> [  ...   ]
> [  <cs>  ]
> [<flags> ]
> [mcount-ret] <- &(pt_regs.sp)
> [ret-addr]
> [  arg1  ]
> [  arg2  ]
> 
> I think this is hard to solve without a tricky hack.

Is this for handling kretprobes? With mcount, we shouldn't be doing that
because mcount is not the place that kretprobes should be doing this.
When we add __fentry__, the arch code will be different to handle that
and it shouldn't be too hard to make that work with kretprobes.

> 
> For example, on x86-32, MCOUNT_FRAME_SAVE saves
> flags on the entry which will be <cs> and it saves
> mcount-ret to local stack and moves flags to next entry.
> 
> <save-frame>
> pushf			# save flags on CS(%esp)
> subl $12, %esp		# skip ip, orig_ax and gs
> pushl %fs
> pushl %es
> ...
> pushl %ebx
> movl 56(%esp), %ebx	# load mcount-ret address
> movl 52(%esp), %ebp	# load flags
> movl %ebp, 56(%esp)	# store flags

Nope we don't do anything like this. I've already got x86_32 working
(but maybe it needs more for pt_regs->sp) but why is pushf needed?

-- Steve

> 
> call function (ebx is callee save)
> 
> <restore-frame>
> movl 56(%esp), %ebp	# load flags
> movl %ebp, 52(%esp)	# store flags
> movl %ebx, 56(%esp)	# load mcount-ret address
> ...
> popf
> ret
> 
> Hmm?
> 
> > Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> > ---
> >  arch/x86/include/asm/ftrace.h     |   38 ++++++++++++++++++++----------------
> >  arch/x86/kernel/entry_64.S        |   23 +++++++++++++++++++++-
> >  include/linux/ftrace.h            |   15 ++++++++++++-
> >  kernel/trace/ftrace.c             |   29 ++++++++++++++++++---------
> >  kernel/trace/trace_events.c       |    2 +-
> >  kernel/trace/trace_functions.c    |    7 +++--
> >  kernel/trace/trace_irqsoff.c      |    2 +-
> >  kernel/trace/trace_sched_wakeup.c |    3 +-
> >  kernel/trace/trace_selftest.c     |   15 +++++++++----
> >  kernel/trace/trace_stack.c        |    3 +-
> >  10 files changed, 95 insertions(+), 42 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> > index b3fcf16..0750c2a 100644
> > --- a/arch/x86/include/asm/ftrace.h
> > +++ b/arch/x86/include/asm/ftrace.h
> > @@ -4,26 +4,29 @@
> >  #ifdef __ASSEMBLY__
> >
> >  	.macro MCOUNT_SAVE_FRAME
> > -	/* taken from glibc */
> > -	subq $0x38, %rsp
> > -	movq %rax, (%rsp)
> > -	movq %rcx, 8(%rsp)
> > -	movq %rdx, 16(%rsp)
> > -	movq %rsi, 24(%rsp)
> > -	movq %rdi, 32(%rsp)
> > -	movq %r8, 40(%rsp)
> > -	movq %r9, 48(%rsp)
> > +	 /*
> > +	  * We add enough stack to save all regs,
> > +	  * and we what we need in the location of pt_regs.
> > +	  */
> > +	subq $ORIG_RAX, %rsp
> > +	movq %rax, RAX(%rsp)
> > +	movq %rcx, RCX(%rsp)
> > +	movq %rdx, RDX(%rsp)
> > +	movq %rsi, RSI(%rsp)
> > +	movq %rdi, RDI(%rsp)
> > +	movq %r8, R8(%rsp)
> > +	movq %r9, R9(%rsp)
> >  	.endm
> >
> >  	.macro MCOUNT_RESTORE_FRAME
> > -	movq 48(%rsp), %r9
> > -	movq 40(%rsp), %r8
> > -	movq 32(%rsp), %rdi
> > -	movq 24(%rsp), %rsi
> > -	movq 16(%rsp), %rdx
> > -	movq 8(%rsp), %rcx
> > -	movq (%rsp), %rax
> > -	addq $0x38, %rsp
> > +	movq R9(%rsp), %r9
> > +	movq R8(%rsp), %r8
> > +	movq RDI(%rsp), %rdi
> > +	movq RSI(%rsp), %rsi
> > +	movq RDX(%rsp), %rdx
> > +	movq RCX(%rsp), %rcx
> > +	movq RAX(%rsp), %rax
> > +	addq $ORIG_RAX, %rsp
> >  	.endm
> >
> >  #endif
> > @@ -34,6 +37,7 @@
> >
> >  #if defined(CONFIG_DYNAMIC_FTRACE) && defined(CONFIG_X86_64)
> >  #define ARCH_SUPPORTS_FTRACE_OPS 1
> > +#define ARCH_SUPPORTS_FTRACE_SAVE_REGS 1
> >  #endif
> >
> >  #ifndef __ASSEMBLY__
> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> > index 27adc2b..b77f297 100644
> > --- a/arch/x86/kernel/entry_64.S
> > +++ b/arch/x86/kernel/entry_64.S
> > @@ -78,7 +78,16 @@ ENTRY(ftrace_caller)
> 
> I can see below code before save frame.
> 
> 	cmpl $0, function_trace_stop
> 	jne  ftrace_stub
> 
> Please pushf before comparing it. :)
> Sometimes, the value of eflags is worth to watch.
> I know that SF/ZF will be never used between
> function call, so it is OK if the eflags is saved
> in MCOUNT_SAVE_FRAME.
> 
> >  	MCOUNT_SAVE_FRAME
> >
> >  	leaq function_trace_op, %rdx
> > -	movq 0x38(%rsp), %rdi
> > +
> > +	cmpl $0, ftrace_save_regs
> > +	jne  save_all_regs
> > +
> > +call_func:
> > +
> > +	/* regs go into 4th parameter */
> > +	leaq (%rsp), %rcx
> > +
> > +	movq ORIG_RAX(%rsp), %rdi
> >  	movq 8(%rbp), %rsi
> >  	subq $MCOUNT_INSN_SIZE, %rdi
> >
> > @@ -96,6 +105,18 @@ GLOBAL(ftrace_stub)
> >  	retq
> >  END(ftrace_caller)
> >
> > +save_all_regs:
> > +	/* Save the rest of pt_regs */
> > +	movq %r15, R15(%rsp)
> > +	movq %r14, R14(%rsp)
> > +	movq %r13, R13(%rsp)
> > +	movq %r12, R12(%rsp)
> > +	movq %r10, R10(%rsp)
> > +	movq %rbp, RBP(%rsp)
> > +	movq %rbx, RBX(%rsp)
> > +	jmp call_func
> 
> At least, pt_regs.sp must be saved for accessing
> vars on stack.
> 
> > +
> > +
> >  #else /* ! CONFIG_DYNAMIC_FTRACE */
> >  ENTRY(mcount)
> >  	cmpl $0, function_trace_stop
> 
> You also need to restore the rest of pt_regs if
> ftrace_save_regs is true.
> 
> Thank you,
> 



  reply	other threads:[~2011-08-11 12:59 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-10 16:22 [PATCH 0/5][RFC] kprobes/ftrace: Have kprobes use ftrace on ftrace nops Steven Rostedt
2011-08-10 16:22 ` [PATCH 1/5][RFC] tracing: Clean up tb_fmt to not give faulty compile warning Steven Rostedt
2011-08-10 16:22 ` [PATCH 2/5][RFC] ftrace: Pass ftrace_ops as third parameter to function trace Steven Rostedt
2011-08-10 16:22 ` [PATCH 3/5][RFC] ftrace: Return pt_regs to function trace callback (x86_64 only so Steven Rostedt
2011-08-11  5:55   ` Masami Hiramatsu
2011-08-11 12:59     ` Steven Rostedt [this message]
2011-08-12  0:55       ` Masami Hiramatsu
2011-08-12 13:05         ` Steven Rostedt
2011-08-10 16:22 ` [PATCH 4/5][RFC] kprobes: Inverse taking of module_mutex with kprobe_mutex Steven Rostedt
2011-08-10 16:22 ` [PATCH 5/5][RFC] kprobes: Use ftrace hooks when probing ftrace nops Steven Rostedt
2011-08-11  7:41   ` Masami Hiramatsu
2011-08-11 13:22     ` Steven Rostedt
2011-08-12  2:41       ` Masami Hiramatsu
2011-08-12  5:46       ` Ananth N Mavinakayanahalli
2011-08-12 13:14         ` Steven Rostedt
2011-08-11  0:21 ` [PATCH 0/5][RFC] kprobes/ftrace: Have kprobes use ftrace on " Masami Hiramatsu
2011-08-11  0:34   ` Steven Rostedt
2011-08-11  6:28     ` Masami Hiramatsu
2011-08-11 13:01       ` Steven Rostedt
2011-08-12  2:57         ` Masami Hiramatsu
2011-08-12 13:08           ` Steven Rostedt
2011-08-13 10:09             ` Masami Hiramatsu
2011-08-14  2:58               ` Steven Rostedt
2011-08-14 10:28                 ` Masami Hiramatsu
2011-08-15 13:06                   ` Steven Rostedt
2011-08-17 12:12                     ` Masami Hiramatsu
2011-08-18 20:06                       ` Steven Rostedt
2011-08-19  2:41                         ` Masami Hiramatsu

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=1313067566.18583.288.camel@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=jbaron@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=yrl.pp-manager.tt@hitachi.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®