On Sat, 30 Aug 2025 at 11:31, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> 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.
It actually won't - not unless you also track every mremap etc.
Which is certainly doable, but I'd argue that it's a lot of complexity.
All you really want is an ID for the file mapping, and yes, I agree
that it's very very annoying that we don't have anything that can then
be correlated to user space any other way than also having a stage
that tracks mmap.
I've slept on it and tried to come up with something, and I can't. As
mentioned, the inode->i_ino isn't actually exposed to user space as
such at all for some common filesystems, so while it's very
traditional, it really doesn't actually work. It's also almost
impossible to turn into a path, which is what you often would want for
many cases.
That said, having slept on it, I'm starting to come around to the
inode number model, not because I think it's a good model - it really
isn't - but because it's a very historical mistake.
And in particular, it's the same mistake we made in /proc/<xyz>/maps.
So I think it's very very wrong, but it does have the advantage that
it's a number that we already do export.
But the inode we expose that way isn't actually the
'vma->vm_file->f_inode' as you'd think, it's actually
inode = file_user_inode(vma->vm_file);
which is subtly different for the backing inode case (ie overlayfs).
Oh, how I dislike that thing, but using the same thing as
/proc/<xyz>/maps does avoid some problems.
Linus
