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,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Subject: Re: [PATCH 0/5][RFC] kprobes/ftrace: Have kprobes use ftrace on ftrace nops
Date: Mon, 15 Aug 2011 09:06:02 -0400	[thread overview]
Message-ID: <1313413562.15704.5.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <4E47A33E.5020202@hitachi.com>

On Sun, 2011-08-14 at 19:28 +0900, Masami Hiramatsu wrote:

> > The point I was making is, if I need to get ftrace function tracing
> > being good enough for function graph tracer, then it should work with
> > kprobes without any issues.
> 
> No, I don't think so, because kprobes user may trace a flags register or
> segment registers. However, function graph tracer only needs stack
> register etc. Thus, if ftrace function tracing is good enough for
> kprobes handlers, it is enough for function graph tracer too.

The added code needed for ftrace is not much more. We just need to save
all of pt_regs and that should work (I already save most of it). The
flags can be saved, but things like compare flags will be useless, as
those are used. But compare flags are undefined when calling a function
anyway.


> 
> > If I need to do the work anyway (for
> > function graph tracing) then why not use it directly with kprobes
> > instead of doing more hooks just in the kprobe_trace?
> 
> >From the kprobe-tracer point of view, I don't mind. I just care
> about complexity, and compatibility of kprobe handlers.

Right, so far there's not much changes to the kprobe side. I'll see if I
can make ftrace do all the hard work to get the proper registers. I want
to make as much as possible stay in the generic kprobe code, and not
touch the arch code. But I may still need to do something like
'increment rip' or whatever.

Note, we will need to touch kprobes one way or another. Either we have
kprobes hook to ftrace, or we need to do the nop skip trick, which will
probably be as intrusive in the kprobe code.

Thanks!

-- Steve



  reply	other threads:[~2011-08-15 13:06 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-10 16:22 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
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 [this message]
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=1313413562.15704.5.camel@gandalf.stny.rr.com \
    --to=rostedt@goodmis.org \
    --cc=acme@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --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®