From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Steven Rostedt <rostedt@goodmis.org>,
Josh Poimboeuf <jpoimboe@redhat.com>
Cc: 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: [PATCH -tip v2 0/3] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts
Date: Tue, 17 Jun 2014 21:57:32 +0900 [thread overview]
Message-ID: <53A03B3C.4000300@hitachi.com> (raw)
In-Reply-To: <20140617110436.15167.7179.stgit@kbuild-fedora.novalocal>
(2014/06/17 20:04), Masami Hiramatsu wrote:
> Hi,
>
> Here is the version 2 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.
> In this version, I fixed some bugs in previous version and
> added a patch which made kprobe itself free from IPMODIFY
> except for jprobe.
>
> 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 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.
>
> Testing:
> BTW, I've tested it with samples/kprobes/{k,j}probe_example.ko
> and a small test module which I added to the last of this mail.
>
> Here is the test script. I think I should put this under
> tools/testing, maybe kprobes? or selftest/kprobes?
>
> ----
> #!/bin/bash
>
> echo "IPMODIFY test"
> ADDR=0x`grep do_fork /proc/kallsyms | cut -f 1 -d" "`
>
> echo "Case1: kprobe->jprobe->ipmodify(fail)"
> modprobe kprobe_example
> modprobe jprobe_example
> insmod ./ipmodify.ko && echo "Case1: [FAIL]" || echo "Case1: [OK]"
Oops, I missed the target=$ADDR for these insmod...
Anyway, without passing target=$ADDR option, ipmodify.ko tries to
register ftrace_ops with an empty filter hash which means
trace all functions. So anyway jprobe and that ftrace_ops collide
with each other on the do_fork and the 2nd one should be failed.
Thus, of course this test doesn't fail with or without target=
param.
Thank you,
--
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2014-06-17 12:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-17 11:04 [PATCH -tip v2 0/3] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts Masami Hiramatsu
2014-06-17 11:04 ` [PATCH -tip v2 1/3] ftrace: Simplify ftrace_hash_disable/enable path in ftrace_hash_move Masami Hiramatsu
2014-06-20 2:08 ` Steven Rostedt
2014-06-20 2:14 ` Masami Hiramatsu
2014-06-17 11:04 ` [PATCH -tip v2 2/3] ftrace, kprobes: Support IPMODIFY flag to find IP modify conflict Masami Hiramatsu
2014-06-20 2:48 ` Steven Rostedt
2014-06-23 7:57 ` Masami Hiramatsu
2014-06-17 11:04 ` [PATCH -tip v2 3/3] kprobes: Set IPMODIFY flag only if the probe can change regs->ip Masami Hiramatsu
2014-06-19 12:34 ` Namhyung Kim
2014-06-20 0:09 ` Namhyung Kim
2014-06-20 2:19 ` Masami Hiramatsu
2014-06-17 12:57 ` Masami Hiramatsu [this message]
2014-06-19 2:08 ` [PATCH -tip v2 0/3] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts Josh Poimboeuf
2014-06-19 5:03 ` Masami Hiramatsu
2014-06-19 14:18 ` Josh Poimboeuf
2014-06-20 3:14 ` 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=53A03B3C.4000300@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.