linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	yrl.pp-manager.tt@hitachi.com
Subject: Re: Re: Re: [PATCH 6/9][RFC] kprobes: Allow probe on ftrace reserved text (but move it)
Date: Tue, 08 May 2012 12:08:11 +0900	[thread overview]
Message-ID: <4FA88E1B.1020708@hitachi.com> (raw)
In-Reply-To: <1336394603.14207.117.camel@gandalf.stny.rr.com>

(2012/05/07 21:43), Steven Rostedt wrote:
> On Mon, 2012-05-07 at 20:37 +0900, Masami Hiramatsu wrote:
> 
>> By the way, there is another way to do that transparently which
>> we add a "real_addr" member to struct kprobes and put the real
>> probed address to the member (without changing kp->addr). This
>> will keep API compatibility.
> 
> I like this a lot. Perhaps we don't need a flag at all, and just use
> these two addrs instead?

Yes, just replacing all "*p->addr" and "kp.addr" with real_addr
and copying addr to real_addr when registering. That's the basic
idea.

I just concern about the cost balance... this is feasible, but
we need to change many arch-dependent parts. Do we really need to
pay that cost just for the backward compatibility?

I mean, the kprobes itself can be changed because we don't ensure
the stability of kernel APIs. If so, it looks enough to change the
behavior of kprobes and give an upgrade hint for users (current patch),
isn't it?

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com

  reply	other threads:[~2012-05-08  3:08 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-02 19:24 [PATCH 0/9][RFC] ftrace: ftrace location lookup speedup, and clean ups Steven Rostedt
2012-05-02 19:24 ` [PATCH 1/9][RFC] ftrace: Sort all function addresses, not just per page Steven Rostedt
2012-05-02 19:24 ` [PATCH 2/9][RFC] ftrace: Remove extra helper functions Steven Rostedt
2012-05-02 19:24 ` [PATCH 3/9][RFC] ftrace: Speed up search by skipping pages by address Steven Rostedt
2012-05-02 19:24 ` [PATCH 4/9][RFC] ftrace: Consolidate ftrace_location() and ftrace_text_reserved() Steven Rostedt
2012-05-02 19:24 ` [PATCH 5/9][RFC] ftrace: Return record ip addr for ftrace_location() Steven Rostedt
2012-05-02 19:24 ` [PATCH 6/9][RFC] kprobes: Allow probe on ftrace reserved text (but move it) Steven Rostedt
2012-05-02 20:40   ` Frank Ch. Eigler
2012-05-02 23:40     ` Steven Rostedt
2012-05-07 11:37       ` Masami Hiramatsu
2012-05-07 11:59         ` Masami Hiramatsu
2012-05-07 12:44           ` Steven Rostedt
2012-05-07 12:51             ` Steven Rostedt
2012-05-07 12:43         ` Steven Rostedt
2012-05-08  3:08           ` Masami Hiramatsu [this message]
2012-05-08 13:04             ` Steven Rostedt
2012-05-09  5:53               ` Masami Hiramatsu
2012-05-09  8:12                 ` Masami Hiramatsu
2012-05-09  9:02                   ` Masami Hiramatsu
2012-05-09 14:50                     ` Steven Rostedt
2012-05-10 11:54                     ` [RFC PATCH -tip ] x86/kprobes: kprobes call optimization Masami Hiramatsu
2012-05-11  8:29                       ` Masami Hiramatsu
2012-05-02 19:24 ` [PATCH 7/9][RFC] ftrace: Make ftrace_modify_all_code() global for archs to use Steven Rostedt
2012-05-02 19:24 ` [PATCH 8/9][RFC] ftrace/x86: Have x86 ftrace use the ftrace_modify_all_code() Steven Rostedt
2012-05-02 19:24 ` [PATCH 9/9][RFC] ftrace: Remove selecting FRAME_POINTER with FUNCTION_TRACER Steven Rostedt

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=4FA88E1B.1020708@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=akpm@linux-foundation.org \
    --cc=fche@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --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;
as well as URLs for NNTP newsgroup(s).