From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>,
Josh Poimboeuf <jpoimboe@kernel.org>,
x86@kernel.org, Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Indu Bhagat <indu.bhagat@oracle.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
linux-perf-users@vger.kernel.org, Mark Brown <broonie@kernel.org>,
linux-toolchains@vger.kernel.org, Jordan Rome <jordalgo@meta.com>,
Sam James <sam@gentoo.org>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Jens Remus <jremus@linux.ibm.com>,
Florian Weimer <fweimer@redhat.com>,
Andy Lutomirski <luto@kernel.org>, Weinan Liu <wnliu@google.com>,
Blake Jones <blakejones@google.com>,
Beau Belgrave <beaub@linux.microsoft.com>,
"Jose E. Marchesi" <jemarch@gnu.org>,
Alexander Aring <aahringo@redhat.com>
Subject: [PATCH v5 8/9] tracing: Have deferred user space stacktrace show file offsets
Date: Thu, 24 Apr 2025 15:25:04 -0400 [thread overview]
Message-ID: <20250424192613.695828192@goodmis.org> (raw)
In-Reply-To: 20250424192456.851953422@goodmis.org
From: Steven Rostedt <rostedt@goodmis.org>
Instead of showing the IP address of the user space stack trace, which is
where ever it was mapped by the kernel, show the offsets of where it would
be in the file.
Instead of:
trace-cmd-1066 [007] ..... 67.770256: <user stack unwind>
cookie=7000000000009
=> <00007fdbd0d421ca>
=> <00007fdbd0f3be27>
=> <00005635ece557e7>
=> <00005635ece559d3>
=> <00005635ece56523>
=> <00005635ece6479d>
=> <00005635ece64b01>
=> <00005635ece64bc0>
=> <00005635ece53b7e>
=> <00007fdbd0c6bca8>
Which is the addresses of the functions in the virtual address space of
the process. Have it record:
trace-cmd-1090 [003] ..... 180.779876: <user stack unwind>
cookie=3000000000009
=> <00000000001001ca>
=> <000000000000ae27>
=> <00000000000107e7>
=> <00000000000109d3>
=> <0000000000011523>
=> <000000000001f79d>
=> <000000000001fb01>
=> <000000000001fbc0>
=> <000000000000eb7e>
=> <0000000000029ca8>
Which is the offset from code where it was mapped at. To find this
address, the mmap_read_lock is taken and the vma is searched for the
addresses. Then what is recorded is simply:
(addr - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
---
kernel/trace/trace.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 71340207321e..f9eb0f7d649c 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3085,18 +3085,27 @@ static void trace_user_unwind_callback(struct unwind_work *unwind,
struct trace_buffer *buffer = tr->array_buffer.buffer;
struct userunwind_stack_entry *entry;
struct ring_buffer_event *event;
+ struct mm_struct *mm = current->mm;
unsigned int trace_ctx;
+ struct vm_area_struct *vma = NULL;
unsigned long *caller;
unsigned int offset;
int len;
int i;
+ /* This should never happen */
+ if (!mm)
+ return;
+
if (!(tr->trace_flags & TRACE_ITER_USERSTACKTRACE_DELAY))
return;
len = trace->nr * sizeof(unsigned long) + sizeof(*entry);
trace_ctx = tracing_gen_ctx();
+
+ guard(mmap_read_lock)(mm);
+
event = __trace_buffer_lock_reserve(buffer, TRACE_USER_UNWIND_STACK,
len, trace_ctx);
if (!event)
@@ -3113,7 +3122,16 @@ static void trace_user_unwind_callback(struct unwind_work *unwind,
caller = (void *)entry + offset;
for (i = 0; i < trace->nr; i++) {
- caller[i] = trace->entries[i];
+ unsigned long addr = trace->entries[i];
+
+ if (!vma || addr < vma->vm_start || addr >= vma->vm_end)
+ vma = vma_lookup(mm, addr);
+
+ if (!vma) {
+ caller[i] = addr;
+ continue;
+ }
+ caller[i] = (addr - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
}
__buffer_unlock_commit(buffer, event);
--
2.47.2
next prev parent reply other threads:[~2025-04-24 19:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-24 19:24 [PATCH v5 0/9] tracing: Deferred unwinding of user space stack traces Steven Rostedt
2025-04-24 19:24 ` [PATCH v5 1/9] unwind_user/deferred: Add deferred unwinding interface Steven Rostedt
2025-04-24 19:24 ` [PATCH v5 2/9] unwind_user/deferred: Make unwind deferral requests NMI-safe Steven Rostedt
2025-04-24 19:24 ` [PATCH v5 3/9] unwind deferred: Use bitmask to determine which callbacks to call Steven Rostedt
2025-04-28 16:33 ` Mathieu Desnoyers
2025-04-28 16:56 ` Steven Rostedt
2025-04-28 18:00 ` Mathieu Desnoyers
2025-04-28 18:12 ` Steven Rostedt
2025-04-28 18:13 ` Mathieu Desnoyers
2025-04-24 19:25 ` [PATCH v5 4/9] tracing: Do not bother getting user space stacktraces for kernel threads Steven Rostedt
2025-04-24 19:25 ` [PATCH v5 5/9] tracing: Rename __dynamic_array() to __dynamic_field() for ftrace events Steven Rostedt
2025-04-24 19:25 ` [PATCH v5 6/9] tracing: Implement deferred user space stacktracing Steven Rostedt
2025-04-24 19:25 ` [PATCH v5 7/9] mm: Add guard for mmap_read_lock Steven Rostedt
2025-04-24 19:25 ` Steven Rostedt [this message]
2025-04-24 19:25 ` [PATCH v5 9/9] tracing: Show inode and device major:minor in deferred user space stacktrace Steven Rostedt
2025-04-24 19:29 ` [PATCH v5 0/9] tracing: Deferred unwinding of user space stack traces Steven Rostedt
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=20250424192613.695828192@goodmis.org \
--to=rostedt@goodmis.org \
--cc=aahringo@redhat.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=andrii.nakryiko@gmail.com \
--cc=beaub@linux.microsoft.com \
--cc=blakejones@google.com \
--cc=broonie@kernel.org \
--cc=fweimer@redhat.com \
--cc=indu.bhagat@oracle.com \
--cc=irogers@google.com \
--cc=jemarch@gnu.org \
--cc=jolsa@kernel.org \
--cc=jordalgo@meta.com \
--cc=jpoimboe@kernel.org \
--cc=jremus@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=sam@gentoo.org \
--cc=wnliu@google.com \
--cc=x86@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