From: Jessica Yu <jeyu@kernel.org>
To: Masami Hiramatsu <mhiramat@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>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
Joe Lawrence <joe.lawrence@redhat.com>,
Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
Steven Rostedt <rostedt@goodmis.org>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
Jessica Yu <jeyu@kernel.org>
Subject: [PATCH 0/2] kprobes: improve error handling when arming/disarming kprobes
Date: Wed, 4 Oct 2017 21:14:12 +0200 [thread overview]
Message-ID: <20171004191414.8872-1-jeyu@kernel.org> (raw)
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(-)
--
2.13.6
next reply other threads:[~2017-10-04 19:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-04 19:14 Jessica Yu [this message]
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 ` [PATCH 0/2] kprobes: improve error handling when arming/disarming kprobes Steven Rostedt
2017-10-05 6:09 ` 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=20171004191414.8872-1-jeyu@kernel.org \
--to=jeyu@kernel.org \
--cc=ananth@linux.vnet.ibm.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=davem@davemloft.net \
--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 \
--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.