Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 25 Jul 2019 09:43:16 +0900
From:   Masami Hiramatsu <mhiramat@kernel.org>
To:     Masami Hiramatsu <mhiramat@kernel.org>
Cc:     Joe Lawrence <joe.lawrence@redhat.com>,
        live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: kprobes, livepatch and FTRACE_OPS_FL_IPMODIFY
Message-Id: <20190725094316.c6bf2524e4e925d9cc5937d1@kernel.org>
In-Reply-To: <20190725093208.343db9d54f6a0f5abc99af7b@kernel.org>
References: <20190724151942.GA7205@redhat.com>
        <20190725093208.343db9d54f6a0f5abc99af7b@kernel.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Joe,

On Thu, 25 Jul 2019 09:32:08 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> NO, that flag has been shared among all ftrace-based kprobes, and checked
> when registering. So what we need is to introduce a new kprobe flag which
> states that this kprobe doesn't modify regs->ip. And kprobe prepare 2 ftrace_ops
> 1 is for IPMODIFY and 1 is for !IPMODIFY.

Ah, OK. We don't even need the new flag.

-----
The jump optimization changes the kprobe's pre_handler behavior.
Without optimization, the pre_handler can change the kernel's execution
path by changing regs->ip and returning 1.  However, when the probe
is optimized, that modification is ignored.  Thus, if you want to
tweak the kernel's execution path, you need to suppress optimization,
using one of the following techniques:

- Specify an empty function for the kprobe's post_handler.

or

- Execute 'sysctl -w debug.kprobes_optimization=n'
-----

So if we remove latter one, all kprobes which change regs->ip must
set a dummy post_handler. 

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>