From: Masami Hiramatsu <mhiramat@kernel.org>
To: Jessica Yu <jeyu@redhat.com>
Cc: Petr Mladek <pmladek@suse.com>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: livepatch/kprobes incompatibility
Date: Thu, 25 Aug 2016 00:16:46 +0900 [thread overview]
Message-ID: <20160825001646.3c2ee1034b80844d35c8f569@kernel.org> (raw)
In-Reply-To: <20160824011300.GA31704@packer-debian-8-amd64.digitalocean.com>
On Tue, 23 Aug 2016 21:13:00 -0400
Jessica Yu <jeyu@redhat.com> wrote:
> Hi Masami, Petr,
>
> I'm trying to figure out where we are exactly with fixing the problems with
> livepatch + kprobes, and I was wondering if there will be any more updates to
> the ipmodify patchset that was originally merged back in 2014 (See:
> https://lkml.org/lkml/2014/11/20/808). It seems that patch 4/5 ("kprobes: Set
> IPMODIFY flag only if the probe can change regs->ip") wasn't merged due to
> other ongoing work, and this patch in particular was needed to enforce a hard
> conflict between livepatch and jprobes while still enabling livepatch and
> kprobes to co-exist.
Hmm, it seems I have missed to follow it up.
I'll try refresh it for the latest kernel again.
> Currently, it looks like livepatch/kpatch and kprobes are still in direct
> conflict, since both kprobe_ftrace_ops and klp_ops have FTRACE_OPS_FL_IPMODIFY
> set. *But* it seems like this mutual exclusion wasn't 100% implemented; I'm
> not sure if this was intentional, but kprobes registration will still return
> success even when ftrace registration fails due to an ipmodify conflict, and
> instead we just get WARNs (See: arm_kprobe_ftrace()).
>
> So we still end up with buggy situations like the following:
> (1) livepatch patches meminfo_proc_show [ succeeds ]
> (2) systemtap probes meminfo_proc_show (using kprobes) [ fails ]
> * BUT from the user's perspective, it would look like systemtap succeeded,
> since register_kprobe() returned success, but the handler will never fire
> and only when we look at dmesg do we see that something went wrong
> (i.e. ftrace registration had failed since livepatch already reserved
> ipmodify in step 1).
>
> From what I understand though, there was work being planned to limit this
> direct conflict to just livepatch and jprobes, since most of the time kprobes
> doesn't change regs->ip. Just wondering what the current state of this work is.
Right, jprobes and livepatch can not work together, but kprobe should be
available.
Thanks,
--
Masami Hiramatsu <mhiramat@kernel.org>
prev parent reply other threads:[~2016-08-24 15:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-24 1:13 Jessica Yu
2016-08-24 9:39 ` Petr Mladek
2016-08-24 15:23 ` Masami Hiramatsu
2016-08-25 16:08 ` Josh Poimboeuf
2016-08-24 15:16 ` 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=20160825001646.3c2ee1034b80844d35c8f569@kernel.org \
--to=mhiramat@kernel.org \
--cc=jeyu@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.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
Powered by JetHome