On 2025-08-28 14:58, Arnaldo Carvalho de Melo wrote:
On August 28, 2025 3:39:35 PM GMT-03:00, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
On Thu, 28 Aug 2025 at 11:05, Steven Rostedt <rostedt@xxxxxxxxxx> wrote:
The deferred user space stacktrace event already does a lookup of the vma
for each address in the trace to get the file offset for those addresses,
it can also report the file itself.
That sounds like a good idea..
But the implementation absolutely sucks:
Add two more arrays to the user space stacktrace event. One for the inode
number, and the other to store the device major:minor number. Now the
output looks like this:
WTF? Why are you back in the 1960's? What's next? The index into the
paper card deck?
Stop using inode numbers and device numbers already. It's the 21st
century. No, cars still don't fly, but dammit, inode numbers were a
great idea back in the days, but they are not acceptable any more.
They *particularly* aren't acceptable when you apparently think that
they are 'unsigned long'. Yes, that's the internal representation we
use for inode indexing, but for example on nfs the inode is actually
bigger. It's exposed to user space as a u64 through
stat->ino = nfs_compat_user_ino64(NFS_FILEID(inode));
so the inode that user space sees in 'struct stat' (a) doesn't
actually match inode->i_ino, and (b) isn't even the full file ID that
NFS actually uses.
Let's not let that 60's thinking be any part of a new interface.
Give the damn thing an actual filename or something *useful*, not a
number that user space can't even necessarily match up to anything.
A build ID?
PERF_RECORD_MMAP went thru this, filename -> inode -> Content based hash
FWIW, we record:
- executable or shared library path name,
- build id (if available),
- debug link (if available),
in LTTng-UST when we dump the loaded executable and libraries from
userspace.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
