Re: [PATCH 0/1] uprobes/tracing: Don't pass addr=ip to perf_trace_buf_submit()

From: Masami Hiramatsu
Date: Thu Apr 11 2013 - 06:39:04 EST

(2013/04/10 23:58), Oleg Nesterov wrote:
> On 04/08, Masami Hiramatsu wrote:
>> (2013/04/06 0:01), Oleg Nesterov wrote:
>>> Masami, perhaps you can also answer the question I asked in 0/4
>>> ?
>>> Off-topic question... Why uprobe_perf_func() passes "addr = ip" to
>>> perf_trace_buf_submit() ? This just sets perf_sample_data->addr for
>>> PERF_SAMPLE_ADDR, do we really need this? and we already have
>>> perf_sample_data->ip initialized by perf.
>>> kprobe_perf_func() and kretprobe_perf_func() do the same.
>> Good catch! I guess that I might misunderstood that it was used
>> for sampling execution address. It should be replaced with (u64)0,
>> as perf_trace_##call() does.
> Thanks!
> How about this trivial cleanup then? If I have your ack I'll add this
> patch to other pending changes.

That is good for me :)

> And... Cough, another question ;) To simplify, lets discuss kprobe_perf_func()
> only. Suppose that a task hits the kprobe but this task/cpu doesn't have
> a counter. Can't we avoid perf_trace_buf_prepare/submit in this case?
> IOW, what do you think about the change below?

Hmm, I'm not so sure how frequently this happens. And, is this right way to
handle that case? If so, we can do same thing also on trace_events.
(perf_trace_##call in include/trace/ftrace.h)

Thank you,

IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at