From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Petr Mladek <pmladek@suse.cz>
Cc: "David S. Miller" <davem@davemloft.net>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Jiri Kosina <jkosina@suse.cz>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] kprobe: Handle error when Kprobe ftrace arming fails
Date: Fri, 27 Feb 2015 16:32:01 +0900 [thread overview]
Message-ID: <54F01D71.1030303@hitachi.com> (raw)
In-Reply-To: <1424967232-2923-1-git-send-email-pmladek@suse.cz>
Hi Petr,
(2015/02/27 1:13), Petr Mladek wrote:
> arm_kprobe_ftrace() could fail, especially after introducing ftrace IPMODIFY
> flag and LifePatching. This patch set adds the error handling and also some
> related fixes.
Hmm, I'd like to drop IPMODIFY from kprobes except for jprobes,
since it actually doesn't change regs->ip which was sent before.
It seems that this series partly covers that work.
> 1st patch includes the most important change. It helps to keep Kprobes
> in a sane state.
>
> 2nd and 3rd patch allows to propagate the error where needed.
OK, I think the 1st one could be merged. 2nd and 3rd one still have some
issues as far as I reviewed.
> The other patches fix problems with the global kprobes_all_disarmed flag.
> They were there even before but they become more visible and critical
> after the arming errors became propagated.
Could you separate the series? And also I doubt we need to show global
disable status, since we can check it via debugfs too (and looks redundant).
Thank you,
> The first patch looks rather safe and might be suitable even for 4.0.
>
> However, I would feel more comfortable if the other patches get some
> testing in linux-next. I did quite some testing and did my best. But
> I started with the three patches and was surprised by the effect of
> the propagated errors. They triggered that BUG_ON() in
> __unregister_kprobe_top() are required the other patches
> to get it working. I wonder if there is any other scenario that
> I have missed.
>
> Of course, I also wait for feedback how to make things better.
>
>
> Petr Mladek (7):
> kprobes: Disable Kprobe when ftrace arming fails
> kprobes: Propagate error from arm_kprobe_ftrace()
> kprobes: Propagate error from disarm_kprobe_ftrace()
> kprobes: Keep consistent state of kprobes_all_disarmed
> kprobes: Do not try to disarm already disarmed Kprobe
> kprobes: Check kprobes_all_disarmed in kprobe_disarmed()
> kprobes: Mark globally disabled Kprobes in debugfs interface
>
> Documentation/kprobes.txt | 5 +-
> kernel/kprobes.c | 279 ++++++++++++++++++++++++++++++++++------------
> 2 files changed, 213 insertions(+), 71 deletions(-)
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com
next prev parent reply other threads:[~2015-02-27 7:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 16:13 [PATCH 0/7] kprobe: Handle error when Kprobe ftrace arming fails Petr Mladek
2015-02-26 16:13 ` [PATCH 1/7] kprobes: Disable Kprobe when " Petr Mladek
2015-02-27 6:26 ` Masami Hiramatsu
2015-02-26 16:13 ` [PATCH 2/7] kprobes: Propagate error from arm_kprobe_ftrace() Petr Mladek
2015-02-27 7:35 ` Masami Hiramatsu
2015-02-26 16:13 ` [PATCH 3/7] kprobes: Propagate error from disarm_kprobe_ftrace() Petr Mladek
2015-02-27 8:01 ` Masami Hiramatsu
2015-02-26 16:13 ` [PATCH 4/7] kprobes: Keep consistent state of kprobes_all_disarmed Petr Mladek
2015-02-26 16:13 ` [PATCH 5/7] kprobes: Do not try to disarm already disarmed Kprobe Petr Mladek
2015-02-26 16:13 ` [PATCH 6/7] kprobes: Check kprobes_all_disarmed in kprobe_disarmed() Petr Mladek
2015-02-26 16:13 ` [PATCH 7/7] kprobes: Mark globally disabled Kprobes in debugfs interface Petr Mladek
2015-02-27 7:32 ` Masami Hiramatsu [this message]
2015-03-12 16:33 ` [PATCH 0/7] kprobe: Handle error when Kprobe ftrace arming fails Petr Mladek
2015-03-13 12:36 ` 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=54F01D71.1030303@hitachi.com \
--to=masami.hiramatsu.pt@hitachi.com \
--cc=ananth@in.ibm.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=davem@davemloft.net \
--cc=fweisbec@gmail.com \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pmladek@suse.cz \
--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.