Re: [PATCH v6 5/6] tracing: Show inode and device major:minor in deferred user space stacktrace

On August 28, 2025 3:39:35 PM GMT-03:00, Linus Torvalds [off-list ref] wrote:

On Thu, 28 Aug 2025 at 11:05, Steven Rostedt [off-list ref] wrote:

quoted

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:

quoted

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

- Arnaldo