From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
Ingo Molnar <mingo@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Subject: Re: Re: [PATCH ftrace/for-next v5 0/5] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts
Date: Fri, 10 Oct 2014 10:03:18 +0900 [thread overview]
Message-ID: <54373056.7070001@hitachi.com> (raw)
In-Reply-To: <20141009112157.17a52571@gandalf.local.home>
(2014/10/10 0:21), Steven Rostedt wrote:
> On Thu, 09 Oct 2014 13:00:59 +0000
> Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:
>
>> Hi,
>>
>> Here is the 5th version of the series of patches which introduces
>> IPMODIFY flag for ftrace_ops to detect conflicts of ftrace users
>> who can modify regs->ip in their handler.
>>
>> The previous version is here;
>> https://lkml.org/lkml/2014/7/28/13
>>
>> This version is basically an update of previous version to the
>> latest ftrace tree, and adding a test code to selftest.
>>
>> Currently, only kprobes can change the regs->ip in the handler,
>> but recently kpatch is also want to change it. Moreover, since
>> the ftrace itself exported to modules, it might be considerable
>> senario.
>>
>> Here we talked on github.
>> https://github.com/dynup/kpatch/issues/47
>>
>> To protect modified regs-ip from each other, this series
>> introduces FTRACE_OPS_FL_IPMODIFY flag and ftrace now ensures
>> the flag can be set on each function entry location. If there
>> is someone who already reserve regs->ip on target function
>> entry, ftrace_set_filter_ip or register_ftrace_function will
>> return -EBUSY. Users must handle that.
>> The ftrace_ops with IPMODIFY flag requires at least one
>> entry for filter hash, and its notrace_hash must be empty,
>> because the IPMODIFY action is very address sensitve and
>> user must consider the ip address.
>>
>> The 3rd patch adds a special reservation of IPMODIFY on the
>> jprobed address, since it is the only user who will change
>> the regs->ip. Other kprobes do not change it anymore.
>>
>> Thank you,
>>
>
> Masami,
>
> Thanks for sending this. I'm going to look at it after Dusseldorf. It's
> too late to get it into 3.18, but it looks like a good fit for the work
> I have for 3.19.
Yeah, I think there is no problem until someone tries to use
both ftrace and jprobe on the same target.
> Just don't let me forget you sent this :-) Even though I tagged it as
> important, I'm sure I'll be tagging a lot of other emails as important
> in the next week.
OK, I'll ping after the event.
> Also, my main test box has finally died. I ordered a new motherboard
> (thanks Linus for the suggestion!) and unfortunately it is due to
> arrive tomorrow. That's the same day I leave and I don't trust my wife
> to install it for me ;-)
Oh, that is a bad timing...
> This means I can not do my tests that I like to run before adding to
> linux-next.
OK, so see you in next week :)
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
prev parent reply other threads:[~2014-10-10 1:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-09 13:00 [PATCH ftrace/for-next v5 0/5] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts Masami Hiramatsu
2014-10-09 13:01 ` [PATCH ftrace/for-next v5 1/5] kprobes/ftrace: Recover original IP if pre_handler doesn't change it Masami Hiramatsu
2014-10-09 13:01 ` [PATCH ftrace/for-next v5 2/5] ftrace, kprobes: Support IPMODIFY flag to find IP modify conflict Masami Hiramatsu
2014-10-09 13:01 ` [PATCH ftrace/for-next v5 3/5] kprobes: Add IPMODIFY flag to kprobe_ftrace_ops Masami Hiramatsu
2014-10-09 13:01 ` [PATCH ftrace/for-next v5 4/5] kprobes: Set IPMODIFY flag only if the probe can change regs->ip Masami Hiramatsu
2014-10-09 13:01 ` [PATCH ftrace/for-next v5 5/5] kselftest, ftrace: Add ftrace IPMODIFY flag test Masami Hiramatsu
2014-10-09 15:21 ` [PATCH ftrace/for-next v5 0/5] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts Steven Rostedt
2014-10-10 1:03 ` Masami Hiramatsu [this message]
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=54373056.7070001@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=ananth@in.ibm.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=rostedt@goodmis.org \
/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.