Re: [PATCH ftrace/core v6 4/5] kprobes: Set IPMODIFY flag only if the probe can change regs->ip

Petr Mladek
2015-02-24T08:52:47Z

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