* Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > On Thu, 30 Mar 2017 08:53:32 +0200 > Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > > > > * Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > > > So this is something I missed while the original code was merged, but the concept > > > > looks a bit weird: why do we do any "allocation" while a handler is executing? > > > > > > > > That's fundamentally fragile. What's the maximum number of parallel > > > > 'kretprobe_instance' required per kretprobe - one per CPU? > > > > > > It depends on the place where we put the probe. If the probed function will be > > > blocked (yield to other tasks), then we need a same number of threads on > > > the system which can invoke the function. So, ultimately, it is same > > > as function_graph tracer, we need it for each thread. > > > > So then put it into task_struct (assuming there's no kretprobe-inside-kretprobe > > nesting allowed). > > No, that is possible to put several kretprobes on same thread, e.g. > the func1() is called from func2(), user can put kretprobes for each > function at same time. > So the possible solution is to allocate new return-stack for each task_struct, > and that is what the function-graph tracer did. > > Anyway, I'm considering to integrate kretprobe_instance with the ret_stack. > It will increase memory usage for kretprobes, but can provide safer way > to allocate kretprobe_instance. Ok, that sounds good to me. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
