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]
Date:	Wed, 10 Apr 2013 16:58:18 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.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: [PATCH 0/1] uprobes/tracing: Don't pass addr=ip to
	perf_trace_buf_submit()

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.

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?

Oleg.

--- x/kernel/trace/trace_kprobe.c
+++ x/kernel/trace/trace_kprobe.c
@@ -985,6 +985,10 @@ static __kprobes void kprobe_perf_func(s
 	int size, __size, dsize;
 	int rctx;
 
+	head = this_cpu_ptr(call->perf_events);
+	if (hlist_empty(head))
+		return;
+
 	dsize = __get_data_size(tp, regs);
 	__size = sizeof(*entry) + tp->size + dsize;
 	size = ALIGN(__size + sizeof(u32), sizeof(u64));
@@ -1001,7 +1005,6 @@ static __kprobes void kprobe_perf_func(s
 	memset(&entry[1], 0, dsize);
 	store_trace_args(sizeof(*entry), tp, regs, (u8 *)&entry[1], dsize);
 
-	head = this_cpu_ptr(call->perf_events);
 	perf_trace_buf_submit(entry, size, rctx,
 					entry->ip, 1, regs, head, NULL);
 }

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ