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...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
