linux-kernel - [RFC PATCH 4/9] perf: Don't record frame pointer based user stacktraces if we dump stack and regs

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 for Android: free password hash cracker in your pocket

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

Message-Id: <1286946421-32202-5-git-send-regression-fweisbec@gmail.com>
Date:	Wed, 13 Oct 2010 07:06:56 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Tom Zanussi <tzanussi@...il.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Robert Richter <robert.richter@....com>
Subject: [RFC PATCH 4/9] perf: Don't record frame pointer based user stacktraces if we dump stack and regs

If we record user stack and regs, then don't record frame pointer
based user callchain, because it means we will do the user callchain
with the dwarf CFI information.

I'm not sure this is a good thing. I don't even know why I'm sending
this patch.

User and kernel stack might be selected for other uses than callchain
in the future, this probably shouldn't mess with the regular callchain
code. Instead we should probably have an exclude_callchain_user
attribute, that could be also useful to filter out user callchains
when people don't want them.

Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>
Cc: Ingo Molnar <mingo@...e.hu>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
Cc: Paul Mackerras <paulus@...ba.org>
Cc: Stephane Eranian <eranian@...gle.com>
Cc: Cyrill Gorcunov <gorcunov@...nvz.org>
Cc: Tom Zanussi <tzanussi@...il.com>
Cc: Masami Hiramatsu <mhiramat@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>
Cc: Stephane Eranian <eranian@...gle.com>
Cc: Robert Richter <robert.richter@....com>
---
 kernel/perf_event.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/kernel/perf_event.c b/kernel/perf_event.c
index 0a1f0df..018a098 100644
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -1958,7 +1958,8 @@ put_callchain_entry(int rctx)
 	put_recursion_context(__get_cpu_var(callchain_recursion), rctx);
 }
 
-static struct perf_callchain_entry *perf_callchain(struct pt_regs *regs)
+static struct perf_callchain_entry *
+perf_callchain(struct pt_regs *regs, struct perf_event *event, u64 sample_type)
 {
 	int rctx;
 	struct perf_callchain_entry *entry;
@@ -1983,8 +1984,16 @@ static struct perf_callchain_entry *perf_callchain(struct pt_regs *regs)
 	}
 
 	if (regs) {
-		perf_callchain_store(entry, PERF_CONTEXT_USER);
-		perf_callchain_user(entry, regs);
+		/*
+		 * CHECKME: if user regs and user stack dumps are used
+		 * for something else than callchains one day, we may
+		 * want a exclude_callchain_user?
+		 */
+		if (!(sample_type & PERF_SAMPLE_UREGS &&
+		      event->attr.ustack_dump_size)) {
+			perf_callchain_store(entry, PERF_CONTEXT_USER);
+			perf_callchain_user(entry, regs);
+		}
 	}
 
 exit_put:
@@ -3760,7 +3769,7 @@ void perf_prepare_sample(struct perf_event_header *header,
 	if (sample_type & PERF_SAMPLE_CALLCHAIN) {
 		int size = 1;
 
-		data->callchain = perf_callchain(regs);
+		data->callchain = perf_callchain(regs, event, sample_type);
 
 		if (data->callchain)
 			size += data->callchain->nr;
-- 
1.6.2.3

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