linux-kernel - Re: [PATCH 0/1] uprobes/tracing: Don't pass addr=ip to perf_trace_buf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <516692BF.6070904@hitachi.com>
Date:	Thu, 11 Apr 2013 19:38:55 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Anton Arapov <anton@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	"yrl.pp-manager.tt@...achi.com" <yrl.pp-manager.tt@...achi.com>
Subject: Re: [PATCH 0/1] uprobes/tracing: Don't pass addr=ip to perf_trace_buf_submit()

(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
>>> marc.info/?l=linux-kernel&m=136458107403835 ?
>>>
>>> 	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,


-- 
Masami HIRAMATSU
IT Management Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/