From: Peter Zijlstra <peterz@infradead.org>
To: Aleksa Sarai <cyphar@cyphar.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Robert Richter <rric@kernel.org>,
Brendan Gregg <bgregg@netflix.com>,
linux-kernel@vger.kernel.org, oprofile-list@lists.sf.net
Subject: Re: [RFC] Merging ftrace_stack, perf_callchain, oprofile->backtrace and stack_trace
Date: Sun, 21 Oct 2018 22:13:58 +0200 [thread overview]
Message-ID: <20181021201358.GF4931@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20181021093106.mhjpb2rnx6kstjki@ryuk>
On Sun, Oct 21, 2018 at 08:31:06PM +1100, Aleksa Sarai wrote:
> Hi all,
>
> I'm currently working on a patchset to make kretprobes produce
> reasonable stack traces[1], and it appears this is a generic problem
> across the entire kernel -- you can see the same kretprobe_trampoline()
> issue when using ftrace just as much as bpf_trace.
>
> However, in working on this patch, I've noticed that there appear to be
> several different implementations of "get the stack trace from this
> pt_regs" which all appear quite similar. Namely:
>
> * struct ftrace_stack;
> * struct perf_callchain_entry; [**]
> * struct stack_trace;
the perf thing also does userspace stack, where the others do not afaik.
And for the kernel part it already uses the regular kernel unwinder.
I'm not sure what you're proposing.
next prev parent reply other threads:[~2018-10-22 9:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-21 9:31 [RFC] Merging ftrace_stack, perf_callchain, oprofile->backtrace and stack_trace Aleksa Sarai
2018-10-21 9:41 ` Aleksa Sarai
2018-10-21 20:13 ` Peter Zijlstra [this message]
2018-10-22 15:26 ` Aleksa Sarai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181021201358.GF4931@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=bgregg@netflix.com \
--cc=cyphar@cyphar.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=oprofile-list@lists.sf.net \
--cc=rostedt@goodmis.org \
--cc=rric@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox