From: Steven Rostedt <rostedt@goodmis.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Jessica Yu <jeyu@kernel.org>, Petr Mladek <pmladek@suse.com>,
Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
"David S . Miller" <davem@davemloft.net>,
Ingo Molnar <mingo@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Joe Lawrence <joe.lawrence@redhat.com>,
Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] kprobes: improve error handling when arming/disarming kprobes
Date: Wed, 4 Oct 2017 15:44:13 -0400 [thread overview]
Message-ID: <20171004154413.30daa238@gandalf.local.home> (raw)
In-Reply-To: <20171004191414.8872-1-jeyu@kernel.org>
Masami,
Can you review these patches?
-- Steve
On Wed, 4 Oct 2017 21:14:12 +0200
Jessica Yu <jeyu@kernel.org> wrote:
> Hi,
>
> This patchset attempts to improve error handling when arming or disarming
> ftrace-based kprobes. The current behavior is to simply WARN when ftrace
> (un-)registration fails, without propagating the error code. This can lead
> to confusing situations where, for example, register_kprobe()/enable_kprobe()
> would return 0 indicating success even if arming via ftrace had failed. In
> this scenario we'd end up with a non-functioning kprobe even though kprobe
> registration (or enablement) returned success. In this patchset, we take
> errors from ftrace into account and propagate the error when we cannot arm
> or disarm a kprobe.
>
> Below is an example that illustrates the problem using livepatch and
> systemtap (which uses kprobes underneath). Both livepatch and kprobes use
> ftrace ops with the IPMODIFY flag set, so registration at the same
> function entry is limited to only one ftrace user.
>
> Before
> ------
> # modprobe livepatch-sample # patches cmdline_proc_show, ftrace ops has IPMODIFY set
> # stap -e 'probe kernel.function("cmdline_proc_show").call { printf ("cmdline_proc_show\n"); }'
>
> .. (nothing prints after reading /proc/cmdline) ..
>
> The systemtap handler doesn't execute due to a kprobe arming failure caused
> by a ftrace IPMODIFY conflict with livepatch, and there isn't an obvious
> indication of error from systemtap (because register_kprobe() returned
> success) unless the user inspects dmesg.
>
> After
> -----
> # modprobe livepatch-sample
> # stap -e 'probe kernel.function("cmdline_proc_show").call { printf ("cmdline_proc_show\n"); }'
> WARNING: probe kernel.function("cmdline_proc_show@/home/jeyu/work/linux-next/fs/proc/cmdline.c:6").call (address 0xffffffffa82fe910) registration error (rc -16)
>
> Although the systemtap handler doesn't execute (as it shouldn't), the
> ftrace error is propagated and now systemtap prints a visible error message
> stating that (kprobe) registration had failed (because register_kprobe()
> returned an error), along with the propagated error code.
>
> This patchset was based on Petr Mladek's original patchset (patches 2 and 3)
> back in 2015, which improved kprobes error handling, found here:
>
> https://lkml.org/lkml/2015/2/26/452
>
> However, further work on this had been paused since then and the patches
> were not upstreamed.
>
> This patchset has been lightly sanity-tested (on linux-next) with kprobes,
> kretprobes, jprobes, and optimized kprobes. It passes the kprobes smoke
> test, but more testing is greatly appreciated.
>
> Thanks,
>
> Jessica
>
> ---
> Jessica Yu (2):
> kprobes: propagate error from arm_kprobe_ftrace()
> kprobes: propagate error from disarm_kprobe_ftrace()
>
> kernel/kprobes.c | 163 ++++++++++++++++++++++++++++++++++++++-----------------
> 1 file changed, 112 insertions(+), 51 deletions(-)
>
next prev parent reply other threads:[~2017-10-04 19:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-04 19:14 Jessica Yu
2017-10-04 19:14 ` [PATCH 1/2] kprobes: propagate error from arm_kprobe_ftrace() Jessica Yu
2017-10-05 6:23 ` Masami Hiramatsu
2017-10-07 10:52 ` Jessica Yu
2017-10-04 19:14 ` [PATCH 2/2] kprobes: propagate error from disarm_kprobe_ftrace() Jessica Yu
2017-10-05 6:28 ` Masami Hiramatsu
2017-10-04 19:44 ` Steven Rostedt [this message]
2017-10-05 6:09 ` [PATCH 0/2] kprobes: improve error handling when arming/disarming kprobes 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=20171004154413.30daa238@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=ananth@linux.vnet.ibm.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=davem@davemloft.net \
--cc=jeyu@kernel.org \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=pmladek@suse.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
all inboxes | Powered by JetHome®