On Tue 2015-02-24 16:38:18, Masami Hiramatsu wrote: > Hi Petr, > > Sorry I missed this mail.
Thanks a lot for answering it with many valuable information. > (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. I see. It is called this special way (modifies regs->ip), so that registry and stack have the same content as if the probed function was called. > > 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. Great idea. Well, it will solve only already existing Kprobes. > > 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 ;-) I have played with it and realized that only Kprobes framework has information about all existing and newly created Kprobes. Therefore we need to somehow inform it that there is a patch and that the code is redirected. I have a prototype that is introducing a new fake Kprobe, so called Patch Probe. It has new flag KPROBE_FLAG_PATCH and no handlers. Conflicts with existing Kprobes are checked when this special probe is added. Also conflicts with these Patch probes are checked when new normal Kprobe is added. I still want to clean and test it a bit before sending as RFC. > 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. Yup > > 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. Thanks for confirmation. > > 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 have one more patch set in the queue. It better handle errors when kprobe_ftrace_ops could not be registered in arm_kprobe_ftrace() and disarm_kprobe_ftrace(). This one is nearly done. Unfortunately, I had to interupt it because my wife got sick and I had to take care of babies. And then there is the big activity around life patching that we need to somehow handle. Best Regards, Petr -- 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/
