All of lore.kernel.org
 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: Sat, 13 Aug 2011 22:58:04 -0400	[thread overview]
Message-ID: <1313290684.18583.362.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <4E464D6C.9020807@hitachi.com>

On Sat, 2011-08-13 at 19:09 +0900, Masami Hiramatsu wrote:
> (2011/08/12 22:08), Steven Rostedt wrote:
> > On Fri, 2011-08-12 at 11:57 +0900, Masami Hiramatsu wrote:
> >
> >> I don't think it won't work. It can work but on a long way.
> >> Could you tell me your "bigger ideas"? Perhaps, we are on the different
> >> way but aim to same goal.
> >
> > Part of the bigger ideas is to have things like function graph tracing
> > use this, as it will simplify the entry.S code. There's other things
> > that may come out of this too.
> 
> Hmm, I think that the current function graph tracing implementation
> is more scalable than kretprobes, because kretprobe requires
> spinlock on every hit. Moreover, you can't probe NMI handler with
> kprobe, and kprobes on irq-handler are also possible to fail
> because of recursive-call.
> So I don't recommend using kretprobe for function-graph tracer :-(

Sorry for the confusion. My idea is not to use kretprobe with function
graph tracer, but to use the ftrace hooks with the pt_regs and friends
for function graph tracer instead of what it does today, which is to add
function graph code directly into entry.S.

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. 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?

-- Steve



  reply	other threads:[~2011-08-14  2:58 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
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 [this message]
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=1313290684.18583.362.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.