From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752229AbbBXHi2 (ORCPT ); Tue, 24 Feb 2015 02:38:28 -0500 Received: from mail9.hitachi.co.jp ([133.145.228.44]:46385 "EHLO mail9.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750880AbbBXHiZ (ORCPT ); Tue, 24 Feb 2015 02:38:25 -0500 Message-ID: <54EC2A6A.2010007@hitachi.com> Date: Tue, 24 Feb 2015 16:38:18 +0900 From: Masami Hiramatsu Organization: Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Petr Mladek Cc: Steven Rostedt , Josh Poimboeuf , Ananth N Mavinakayanahalli , Jiri Kosina , Seth Jennings , Linux Kernel Mailing List , Vojtech Pavlik , Namhyung Kim , Miroslav Benes , Ingo Molnar Subject: Re: [PATCH ftrace/core v6 4/5] kprobes: Set IPMODIFY flag only if the probe can change regs->ip References: <20141121102502.11844.82696.stgit@localhost.localdomain> <20141121102530.11844.41626.stgit@localhost.localdomain> <20150126161436.GC8244@dhcp128.suse.cz> In-Reply-To: <20150126161436.GC8244@dhcp128.suse.cz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Petr, Sorry I missed this mail. (2015/01/27 1:14), Petr Mladek wrote:> On Fri 2014-11-21 05:25:30, Masami Hiramatsu wrote: >> Set FTRACE_OPS_FL_IPMODIFY flag only for the probes which can change >> regs->ip, which has kprobe->break_handler. >> Currently we can not put jprobe and another ftrace handler which >> changes regs->ip on the same function because all kprobes have >> FTRACE_OPS_FL_IPMODIFY flag. This removes FTRACE_OPS_FL_IPMODIFY >> flag from kprobes and only when the user uses jprobe (or the >> kprobe.break_handler != NULL) we add additinal ftrace_ops with >> FTRACE_OPS_FL_IPMODIFY on target function. > > Please, what are the plans with this patch? Well, I'll revise this for newer kernel. > > I have checked the interference between Kprobes and LivePatching and > here is my observation: > > 1. Jprobe and LivePatch must be in a hard conflict. They both need > to change IP and continue another way after ftrace ops finishes. > > BTW: I wonder a bit why Jprobe handler could not be called directly > from kprobe_ftrace_handler(). I guess that it is because we want > to call the kprobe handler in a sane context: preemption and IRQs > enabled, be able to use traced functions. Right, Jprobe is just a different interface of kprobe handler. It must be called from kprobes. However, I think this is not so hard in practice, since we already have perf-probe which allows us to find which register or stack is assigned to which function parameter. That was the main reason why jprobe is introduced. But now, we have perf-probe or systemtap, we don't(or less) need the hack like jprobe anymore. > 2. Normal Kprobe for the original function is ignored if the function > is patched. > > I am working on a code that will print warning in both > cases. First, when we add a patch and the function has > a Kprobe registered. Second, the function is patched and > we want to add Kprobe for the original version. Thanks! Maybe we can add "Ignored" flag for those kprobes so that users can check it is working or not via debugfs. > I want to make it generic and make it dependent on the > IPMODIFY flag. IMHO, it just could be a handshake between > kprobe and ftrace code. I am still trying to understand > the needed parts of the code ;-) BTW, the kprobes on function entry (iow, ftrace-based kprobes) should not be ignored. Even if we patches a function-body, the entrance address should be same. > 3. Kretprobe could live with a patch without a problem! > > The Kretprobe entry handler is called directly in > kprobe_ftrace_handler() and does not change IP. > On the other hand the LivePatch ftrace handler does > not modify the return address because the return address > is the same for the original and the patched function. Right. > > Or did I miss something? > > This is where this patch might be useful. The other patches > from this patch set are already in Linus' tree and I cannot > find any information about this one. Well, thank you for picking it up! > > I could try to solve remaining problems if there are any. > Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@hitachi.com