On Thu, 28 Aug 2025 at 11:05, Steven Rostedt <rost...@kernel.org> 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.
Linus
