On Fri, 29 Aug 2025 at 09:49, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> What do I use to make the hash?
Literally just '(unsigned long)(vma->vm_file)'.
Nothing else.
> One thing this is trying to do is not have to look up the path name for
> every line of a stack trace.
That's the *opposite* of what I've been suggesting. I've literally
been talking about just saving off the hash of the file pointer.
(And I just suggested that what you actually save off isn't even the
hash - just the value - and that you can hash it later at a less
critical point in time)
Don't do *any* work at all at trace collection time. All you need is
to literally access three fields in the 'vma':
- 'vm_start' and 'vm_pgoff' are needed to calculate the offset in the
file using the user space address
- save off the value of 'vm_file' for later hashing
and I really think you're done.
Then, for the actual trace, you need two things:
- you need the mmap trace event that has the 'file' value, and you
create a mmap event with that value hashed, and at that point you also
output the pathname and/or things like the build ID
- for the stack trace events, you output the offset in the file, and
you hash and output the file value
now, in user space, you have all you need. All you do is match the
hashes. They are random numbers, and user space cannot know what they
are. They are just cookies as a mapping ID.
And look, now you have the pathname and the build ID - or whatever you
saved off in that mmap event. And at stack trace time, you needed to
do *nothing*.
And mmap is rare enough - and heavy enough - that doing that pathname
and build ID at *that* point is a non-issue.
See what I'm trying to say?
Linus
