Quick Recap: The /proc/PID/maps Format

Before diving into the inode and pathname fields, let us quickly revisit the full structure of a single line in /proc/PID/maps. This file gives you the complete memory layout of any running process.

Fields 5 and 6 (highlighted in green) are what this tutorial section focuses on.

Field 5: The Inode Number — The VFS Identity Card

When the kernel maps a file into memory, it needs to track which exact file is being mapped. It does this using the inode number.

An inode is a data structure inside the Virtual FileSystem (VFS) — Linux’s unified file system layer that works the same way regardless of whether you are using ext4, XFS, Btrfs, or any other filesystem. Every file on your system gets its own inode, and that inode stores all the important metadata about the file: its size, ownership, permissions, timestamps, and the list of disk blocks where the data lives.

The inode number in /proc/PID/maps is only present when the mapping comes from an actual file on disk. For memory regions that have no file backing them — things like the stack, the heap, or anonymous mmap() allocations — this field is simply 0.

Let us verify this with the ls -i command, which prints the inode number of any file:

$ ls -i /bin/cat
524313 /bin/cat

The inode number printed by ls -i matches what appears in the memory map. This is the kernel’s way of saying: “this virtual address range is backed by the data from that exact file on disk.”

Field 6: The Pathname — Which File Is Mapped?

The seventh and final field in the maps output tells you the full path of the file whose contents are loaded into that memory region. For a process like cat, the text segment (where machine code lives) will show /bin/cat as its pathname.

When the inode field is non-zero, the pathname is always a real filesystem path. When the inode is zero, this field is empty — or in some special cases it will contain a label in square brackets like [stack], [heap], or [vdso]. These square-bracket labels are inserted by the kernel to help you understand what a particular anonymous region is actually used for.

All Addresses Are Virtual — Why That Matters

Every address you see in /proc/PID/maps is a virtual address, not a physical RAM address. This is a fundamental point worth taking time to understand.

Your CPU does not let programs access physical RAM directly. Instead, each process runs inside its own isolated virtual address space. The kernel, along with the CPU’s Memory Management Unit (MMU), translates every virtual address into a physical one using a set of data structures called page tables. Each process has its own private set of page tables.

Because each process has its own page tables, two different processes can both have a segment starting at the same virtual address (say 0x400000) while pointing to completely different physical memory cells. Their virtual worlds never collide.

The addresses you see are called User Virtual Addresses (UVAs) because they belong to the user-space half of the address space. On a 64-bit x86 system, you will notice that the top 16 bits (the most significant bits) of every UVA are always zero. This is by design — it is how the hardware separates user-space virtual addresses from kernel-space virtual addresses.

# User Virtual Address — top 16 bits are zero
0x0000_55d8_3b65_000   ← this is a UVA (user space)

# Kernel Virtual Address — top 16 bits are all 1s
0xffff_8800_0000_0000  ← this is a KVA (kernel space)

The Special Segments: vsyscall, vvar, and vDSO

When you look at the memory map of any process, you will always see three unusual entries near the very top: [vsyscall], [vvar], and [vdso]. These are not your code and they are not shared libraries you linked against. They are kernel-injected mappings that every process automatically gets.

To understand why they exist, you first need to understand a small problem: system calls are slow.

The solution is to avoid the mode switch entirely for a small set of syscalls that only need to read kernel data, never write it. The three mappings implement this optimization in two generations: