lkml.org 
[lkml]   [2017]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH -tip 0/5] kprobes: Abolish jprobe APIs
On Thu, 5 Oct 2017 16:35:22 -0700
Kees Cook <keescook@chromium.org> wrote:

> On Thu, Oct 5, 2017 at 4:13 PM, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> > Hi,
> >
> > This series abolishes jprobe APIs and remove or disable related
> > code. This is a preparation of removing all jprobe code (including
> > kprobe's break_handler.)
> > I'm not so sure how many jprobe users still exists, but
> > please migrate your tool to trace-event or perf-probe.
> >
> > As we discussed this thread ( https://lkml.org/lkml/2017/10/2/386 ),
> > we decided to remove jprobe.
> >
> > Nowadays ftrace and other tracing features are enough matured
> > to replace jprobe use-cases. Users can safely use ftrace and
> > perf probe etc. for their use cases. So we have better way.
> > IOW, jprobe finished its task.
> >
> > People who still use jprobe, must migrate to other tracing features.
> > Please consider to migrate your tool to following options.
> >
> > - Use trace-event to trace target function with arguments
> > trace-event is a low-overhead (and almost no visible overhead if it
> > is off) statically defined event interface. You can define new events
> > and trace it via ftrace or any other tracing tools.
> > See following urls,
> > - https://lwn.net/Articles/379903/
> > - https://lwn.net/Articles/381064/
> > - https://lwn.net/Articles/383362/
>
> It seems this method requires setting up the target trace ahead of time?
>
> > - Use ftrace dynamic events (kprobe event) with perf-probe
> > If you build your kernel with debug info (CONFIG_DEBUG_INFO), you can
> > find which register/stack is assigned to which local variable or arguments
> > by using perf-probe and set up new event to trace it.
> > See following documents,
> > - Documentation/trace/kprobetrace.txt
> > - Documentation/trace/events.txt
> > - tools/perf/Documentation/perf-probe.txt
>
> These seem to be more about setting up probes from userspace.
>
> > As far as I can see, tcp probe, dccp probe, sctp probe and lkdtm
> > are using jprobe to probe function. Please consider to migrate.
>
> I'm happy to do so, but I'm quite unfamiliar with how to do this (I
> didn't write lkdtm's jprobe code originally). lkdtm just wants to hook
> function entry and call it's own function before.
>
> It uses struct jprobe like this:
>
> .jprobe = { \
> .kp.symbol_name = _symbol, \
> .entry = (kprobe_opcode_t *)_entry, \
> }, \
>
> and defines a bunch of handlers like this for the _symbol and _entry pairs:
>
> "do_IRQ", jp_do_irq),
> ...
> "tasklet_action", jp_tasklet_action),
>
> where all the handlers look exactly the same (and don't care about arguments):

If so, you can just change it to kprobes instead of jprobe.
e.g.

.kprobe = {
.symbol_name = _symbol,
.pre_handler = _entry,
}

and
"do_IRQ", kp_pre_handler),
...
"tasklet_action", kp_pre_handler),

both kp_do_irq and kp_tasklet_action has same signature, so you can
use same function like

static unsigned int kp_pre_handler(struct kprobe *kp, struct pt_regs *regs)
{
lkdtm_handler();
return 0;
}

I think using ftrace gives you lower latency, but you need to depend on
CONFIG_FUNCTION_TRACER instead of CONFIG_KPROBES.

Anyway, please choose either one of those :)

Thank you,

--
Masami Hiramatsu <mhiramat@kernel.org>

\
 
 \ /
  Last update: 2017-10-06 02:33    [W:0.119 / U:0.120 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site