From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
Steven Rostedt <rostedt@kernel.org>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
bpf@vger.kernel.org, x86@kernel.org,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andrii Nakryiko <andrii@kernel.org>,
Indu Bhagat <indu.bhagat@oracle.com>,
"Jose E. Marchesi" <jemarch@gnu.org>,
Beau Belgrave <beaub@linux.microsoft.com>,
Jens Remus <jremus@linux.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Florian Weimer <fweimer@redhat.com>, Sam James <sam@gentoo.org>,
Kees Cook <kees@kernel.org>,
"Carlos O'Donell" <codonell@redhat.com>
Subject: Re: [PATCH v6 5/6] tracing: Show inode and device major:minor in deferred user space stacktrace
Date: Sat, 30 Aug 2025 14:31:14 -0400 [thread overview]
Message-ID: <20250830143114.395ed246@batman.local.home> (raw)
In-Reply-To: <CAHk-=wgNeu8_=kPnKwFpwMUC=o-uh=KjJWePR9ujk=7F9yNXDQ@mail.gmail.com>
On Fri, 29 Aug 2025 17:45:39 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> But what it does *NOT* need is munmap() events.
>
> What it does *NOT* need is translating each hash value for each entry
> by the kernel, when whoever treads the file can just remember and
> re-create it in user space.
If we are going to rely on mmap, then we might as well get rid of the
vma_lookup() altogether. The mmap event will have the mapping of the
file to the actual virtual address.
If we add a tracepoint at mmap that records the path and the address as
well as the permissions of the mapping, then the tracer could then
trace only those addresses that are executable.
To handle missed events, on start of tracing, trigger the mmap event
for every currently running tasks for their executable sections, and
that will allow the tracer to see where the files are mapped.
After that, the stack traces can go back to just showing the virtual
addresses of the user space stack without doing anything else. Let the
trace map the tasks memory to all the mmaps that happened and translate
it that way.
The downside is that there may be a lot of information to record. But
the tracer could choose which task maps to trace via filters and if it's
tracing all tasks, it just needs to make sure its buffer is big enough.
-- Steve
next prev parent reply other threads:[~2025-08-30 18:31 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-28 18:03 [PATCH v6 0/6] tracing: Deferred unwinding of user space stack traces Steven Rostedt
2025-08-28 18:03 ` [PATCH v6 1/6] tracing: Do not bother getting user space stacktraces for kernel threads Steven Rostedt
2025-08-28 18:03 ` [PATCH v6 2/6] tracing: Rename __dynamic_array() to __dynamic_field() for ftrace events Steven Rostedt
2025-08-28 18:03 ` [PATCH v6 3/6] tracing: Implement deferred user space stacktracing Steven Rostedt
2025-08-28 18:03 ` [PATCH v6 4/6] tracing: Have deferred user space stacktrace show file offsets Steven Rostedt
2025-08-28 18:03 ` [PATCH v6 5/6] tracing: Show inode and device major:minor in deferred user space stacktrace Steven Rostedt
2025-08-28 18:39 ` Linus Torvalds
2025-08-28 18:58 ` Arnaldo Carvalho de Melo
2025-08-28 19:02 ` Mathieu Desnoyers
2025-08-28 19:18 ` Linus Torvalds
2025-08-28 20:04 ` Arnaldo Carvalho de Melo
2025-08-28 20:37 ` Linus Torvalds
2025-08-28 20:17 ` Steven Rostedt
2025-08-28 20:27 ` Arnaldo Carvalho de Melo
2025-08-28 20:42 ` Linus Torvalds
2025-08-28 20:51 ` Steven Rostedt
2025-08-28 21:00 ` Arnaldo Carvalho de Melo
2025-08-28 21:27 ` Steven Rostedt
2025-08-29 16:27 ` Sam James
2025-08-28 20:38 ` Linus Torvalds
2025-08-28 20:48 ` Steven Rostedt
2025-08-28 21:06 ` Linus Torvalds
2025-08-28 21:17 ` Steven Rostedt
2025-08-28 22:10 ` Linus Torvalds
2025-08-28 22:44 ` Steven Rostedt
2025-08-29 15:06 ` Steven Rostedt
2025-08-29 15:47 ` Linus Torvalds
2025-08-29 16:07 ` Linus Torvalds
2025-08-29 16:33 ` Steven Rostedt
2025-08-29 16:42 ` Linus Torvalds
2025-08-29 16:50 ` Linus Torvalds
2025-08-29 17:02 ` Steven Rostedt
2025-08-29 17:13 ` Linus Torvalds
2025-08-29 17:57 ` Arnaldo Carvalho de Melo
2025-08-29 20:51 ` Linus Torvalds
2025-08-29 16:57 ` Steven Rostedt
2025-08-29 17:02 ` Linus Torvalds
2025-08-29 17:52 ` Steven Rostedt
2025-08-29 16:19 ` Steven Rostedt
2025-08-29 16:28 ` Linus Torvalds
2025-08-29 16:49 ` Steven Rostedt
2025-08-29 16:59 ` Linus Torvalds
2025-08-29 17:17 ` Arnaldo Carvalho de Melo
2025-08-29 17:33 ` Linus Torvalds
2025-08-29 18:11 ` Steven Rostedt
2025-08-29 20:54 ` Linus Torvalds
2025-08-29 21:18 ` Steven Rostedt
2025-08-29 22:40 ` Linus Torvalds
2025-08-29 23:09 ` Steven Rostedt
2025-08-29 23:42 ` Steven Rostedt
2025-08-30 0:36 ` Steven Rostedt
2025-08-30 0:44 ` Steven Rostedt
2025-08-30 0:45 ` Linus Torvalds
2025-08-30 1:20 ` Steven Rostedt
2025-08-30 1:26 ` Steven Rostedt
2025-08-30 18:31 ` Steven Rostedt [this message]
2025-08-30 19:03 ` Arnaldo Carvalho de Melo
2025-08-30 19:03 ` Linus Torvalds
2025-08-28 18:03 ` [PATCH v6 6/6] tracing: Add an event to map the inodes to their file names 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=20250830143114.395ed246@batman.local.home \
--to=rostedt@goodmis.org \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=arnaldo.melo@gmail.com \
--cc=beaub@linux.microsoft.com \
--cc=bpf@vger.kernel.org \
--cc=codonell@redhat.com \
--cc=fweimer@redhat.com \
--cc=indu.bhagat@oracle.com \
--cc=jemarch@gnu.org \
--cc=jolsa@kernel.org \
--cc=jpoimboe@kernel.org \
--cc=jremus@linux.ibm.com \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@kernel.org \
--cc=sam@gentoo.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--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;
as well as URLs for NNTP newsgroup(s).