* 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). There's just no way in hell we should be calling any complex kernel function from kernel probes! I mean, think about it, a kretprobe can be installed in a lot of places, and now we want to call get_free_pages() from it?? This would add a massive amount of fragility. Instrumentation must be _simple_, every patch that adds more complexity to the most fundamental code path of it should raise a red flag ... So let's make this more robust, ok? 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
