On Thu, 5 Oct 2017 16:35:22 -0700 Kees Cook <[email protected]> wrote:
> On Thu, Oct 5, 2017 at 4:13 PM, Masami Hiramatsu <[email protected]> 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 <[email protected]>
