On August 30, 2025 3:31:14 PM GMT-03:00, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: >On Fri, 29 Aug 2025 17:45:39 -0700 >Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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. > PERF_RECORD_MMAP2 (MMAP had just the filename); <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/perf_event.h#n1057> >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. Perf does synthesize the needed mmap events by traversing procfs, if needed. Jiri at some point toyed with BPF iterators to do as you suggest: from the kernel iterate task structs and generate the PERF_RECORD_MMAP2 for preexisting processes. >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. It is, but for system wide cases, etc. Want to see it all? There's a cost... - Arnaldo 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 - Arnaldo
