mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>

      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