From: Beau Belgrave <beaub@linux.microsoft.com>
To: peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
namhyung@kernel.org, rostedt@goodmis.org, mhiramat@kernel.org,
mathieu.desnoyers@efficios.com
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org, mark.rutland@arm.com,
alexander.shishkin@linux.intel.com, jolsa@kernel.org,
irogers@google.com, adrian.hunter@intel.com, primiano@google.com,
aahringo@redhat.com, dcook@linux.microsoft.com
Subject: [RFC PATCH 3/4] perf/core: Factor perf_output_sample_udump()
Date: Fri, 12 Apr 2024 00:17:31 +0000 [thread overview]
Message-ID: <20240412001732.475-4-beaub@linux.microsoft.com> (raw)
In-Reply-To: <20240412001732.475-1-beaub@linux.microsoft.com>
We now have two user dump sources (stack and tls). Both are doing the
same logic to ensure the user dump ABI output is properly handled. The
only difference is one gets the address within the method, and the other
is passed the address.
Add perf_output_sample_udump() and utilize it for both stack and tls
sample dumps. The sp register is now fetched outside of this method and
passed to it. This allows both stack and tls to utilize the same code.
Signed-off-by: Beau Belgrave <beaub@linux.microsoft.com>
---
kernel/events/core.c | 68 +++++++++++++-------------------------------
1 file changed, 19 insertions(+), 49 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f848bf4be9bd..6b3cf5afdd32 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6998,47 +6998,10 @@ perf_sample_dump_size(u16 dump_size, u16 header_size, u64 task_size)
}
static void
-perf_output_sample_ustack(struct perf_output_handle *handle, u64 dump_size,
- struct pt_regs *regs)
-{
- /* Case of a kernel thread, nothing to dump */
- if (!regs) {
- u64 size = 0;
- perf_output_put(handle, size);
- } else {
- unsigned long sp;
- unsigned int rem;
- u64 dyn_size;
-
- /*
- * We dump:
- * static size
- * - the size requested by user or the best one we can fit
- * in to the sample max size
- * data
- * - user stack dump data
- * dynamic size
- * - the actual dumped size
- */
-
- /* Static size. */
- perf_output_put(handle, dump_size);
-
- /* Data. */
- sp = perf_user_stack_pointer(regs);
- rem = __output_copy_user(handle, (void *) sp, dump_size);
- dyn_size = dump_size - rem;
-
- perf_output_skip(handle, rem);
-
- /* Dynamic size. */
- perf_output_put(handle, dyn_size);
- }
-}
-
-static void
-perf_output_sample_utls(struct perf_output_handle *handle, u64 addr,
- u64 dump_size, struct pt_regs *regs)
+perf_output_sample_udump(struct perf_output_handle *handle,
+ unsigned long addr,
+ u64 dump_size,
+ struct pt_regs *regs)
{
/* Case of a kernel thread, nothing to dump */
if (!regs) {
@@ -7054,7 +7017,7 @@ perf_output_sample_utls(struct perf_output_handle *handle, u64 addr,
* - the size requested by user or the best one we can fit
* in to the sample max size
* data
- * - user tls dump data
+ * - user dump data
* dynamic size
* - the actual dumped size
*/
@@ -7507,9 +7470,16 @@ void perf_output_sample(struct perf_output_handle *handle,
}
if (sample_type & PERF_SAMPLE_STACK_USER) {
- perf_output_sample_ustack(handle,
- data->stack_user_size,
- data->regs_user.regs);
+ struct pt_regs *regs = data->regs_user.regs;
+ unsigned long sp = 0;
+
+ if (regs)
+ sp = perf_user_stack_pointer(regs);
+
+ perf_output_sample_udump(handle,
+ sp,
+ data->stack_user_size,
+ regs);
}
if (sample_type & PERF_SAMPLE_WEIGHT_TYPE)
@@ -7551,10 +7521,10 @@ void perf_output_sample(struct perf_output_handle *handle,
perf_output_put(handle, data->code_page_size);
if (sample_type & PERF_SAMPLE_TLS_USER) {
- perf_output_sample_utls(handle,
- data->tls_addr,
- data->tls_user_size,
- data->regs_user.regs);
+ perf_output_sample_udump(handle,
+ data->tls_addr,
+ data->tls_user_size,
+ data->regs_user.regs);
}
if (sample_type & PERF_SAMPLE_AUX) {
--
2.34.1
next prev parent reply other threads:[~2024-04-12 0:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 0:17 [RFC PATCH 0/4] perf: Correlating user process data to samples Beau Belgrave
2024-04-12 0:17 ` [RFC PATCH 1/4] perf/core: Introduce perf_prepare_dump_data() Beau Belgrave
2024-04-12 0:17 ` [RFC PATCH 2/4] perf: Introduce PERF_SAMPLE_TLS_USER sample type Beau Belgrave
2024-04-12 0:17 ` Beau Belgrave [this message]
2024-04-12 0:17 ` [RFC PATCH 4/4] perf/x86/core: Add tls dump support Beau Belgrave
2024-04-12 4:52 ` [RFC PATCH 0/4] perf: Correlating user process data to samples Ian Rogers
2024-04-12 16:28 ` Beau Belgrave
2024-04-12 18:32 ` Mathieu Desnoyers
2024-04-12 7:12 ` Peter Zijlstra
2024-04-12 16:37 ` Beau Belgrave
2024-04-13 10:53 ` Peter Zijlstra
2024-04-13 12:48 ` Steven Rostedt
2024-04-18 22:53 ` Josh Poimboeuf
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=20240412001732.475-4-beaub@linux.microsoft.com \
--to=beaub@linux.microsoft.com \
--cc=aahringo@redhat.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=dcook@linux.microsoft.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=primiano@google.com \
--cc=rostedt@goodmis.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;
as well as URLs for NNTP newsgroup(s).