Linux Process and Thread Virtual Address Space (VAS): A Complete Guide for Kernel Developers

Part of the Free Linux Kernel Development Course at EmbeddedPathashala • Updated for Linux 6.x

Every time you run a program on Linux, the kernel creates a private virtual address space (VAS) for that process. Understanding how this virtual address space is organized — what lives in it, how threads share it, and how the kernel manages it — is one of the most important foundations of Linux kernel programming and Linux device driver development. In this lecture, part of our free Linux kernel development course, we will walk through the Linux process virtual address space from first principles, updated for Linux 6.x behavior.

What is a Virtual Address Space in Linux?

Modern operating systems, including Linux, do not give a process direct access to physical RAM. Instead, the kernel gives each process its own virtual address space — a large, private range of memory addresses that the process can use as if it owned all of it. Behind the scenes, the CPU’s Memory Management Unit (MMU) translates these virtual addresses into real physical addresses using page tables maintained by the kernel.

This design gives Linux several important benefits:

• Isolation: One process cannot accidentally (or maliciously) read or write another process’s memory.
• Flexibility: The kernel can place data anywhere in physical RAM and map it to a convenient virtual address for the process.
• Overcommit: The total virtual memory used by all processes can exceed the physical RAM available; the kernel uses demand paging to bring pages in only when actually accessed.

On a 64-bit x86 Linux system running Linux 6.x, the virtual address space is enormous — theoretically 2⁶⁴ bytes. In practice, Linux splits the usable 48-bit (or 57-bit with 5-level paging) address range into two halves:

The user space half belongs exclusively to the process. The kernel space half is shared across all processes — but user-mode code cannot access it directly. Attempting to do so results in a segmentation fault (SIGSEGV).

User Space Segments: What Lives in a Process VAS

The user space portion of a process VAS is not a single flat block. The kernel divides it into distinct segments (technically called memory mappings or VMAs — Virtual Memory Areas). Each VMA has its own permissions, purpose, and behavior.

Let’s look at the main segments that make up a typical Linux process in user space:

The Text Segment (Code)

The text segment contains the machine code of your compiled program. It is mapped with read and execute permissions (r-x) but is not writable — this prevents accidental or malicious self-modification of code. On Linux, when multiple processes run the same program (for example, two terminals running bash), they share the same physical pages for the text segment — only one copy lives in RAM. This sharing is handled transparently by the kernel using the MMU.

The Data Segment (Initialized, Uninitialized, Heap)

The data segment covers all global and static variables. It is split into three distinct mappings:

• Initialized data (.data): Global/static variables that have an explicit initial value in your source code. These values are stored in the binary on disk and loaded into memory.
• Uninitialized data / BSS (.bss): Global/static variables that are declared but not initialized. The kernel zero-fills these at process start — it does not need to store them in the binary, saving disk space.
• Heap: The dynamically growing region managed at runtime by malloc() / free() and similar calls. It starts right above BSS and grows upward toward higher addresses as you allocate memory.

## Example: Reading /proc/self/maps on Linux 6.x
## Each line: start-end  permissions  offset  dev  inode  pathname

$ cat /proc/self/maps
55a3f0000000-55a3f0001000 r--p 00000000 08:01 1234567 /bin/cat   ← text (read)
55a3f0001000-55a3f0002000 r-xp 00001000 08:01 1234567 /bin/cat   ← text (exec)
55a3f0002000-55a3f0003000 r--p 00002000 08:01 1234567 /bin/cat   ← rodata
55a3f0004000-55a3f0005000 rw-p 00003000 08:01 1234567 /bin/cat   ← data
55a3f1000000-55a3f1021000 rw-p 00000000 00:00 0        [heap]
7f3b00000000-7f3b001ff000 r--p 00000000 08:01 9876543 /lib/libc.so.6
...
7fff00000000-7fff00021000 rw-p 00000000 00:00 0        [stack]

Library Mappings

When your program uses shared libraries (like libc.so.6, libpthread.so.0, or any custom .so), the dynamic linker (ld.so) maps these into the process’s VAS at runtime. Each shared library gets its own VMA entries — typically one for the code (read + execute), one for read-only data, and one for writable data. The code pages are shared in physical memory across all processes using the same library; only the per-process data pages are private.

Threads and Stacks in the Virtual Address Space

Here is where things get interesting for Linux kernel programming. The relationship between threads and the VAS is fundamental to understanding how the Linux scheduler works and how task_struct is organized.

All Threads in a Process Share the Same VAS

In Linux, a thread is not fundamentally different from a process at the kernel level. Both are represented by a task_struct. The difference is that threads within the same process all share the same virtual address space — they use the same page tables, see the same text segment, the same heap, the same global variables. A process is essentially a group of threads sharing one VAS.

One User Space Stack Per Thread

Even though threads share the text segment, heap, and data segments, every thread needs its own private stack. This is because each thread is executing its own call chain — it may be deep inside some function while another thread is doing something completely different. If threads shared a stack, their function calls would corrupt each other.

So on a system with 1,000 user-mode threads alive, there are 1,000 user space stacks in memory — one per thread. Each stack:

• Grows downward (toward lower addresses) as functions are called.
• Has a default size limit of 8 MB (controlled by the RLIMIT_STACK resource limit).
• Can be inspected using the prlimit or ulimit -s commands.

## Check the stack size limit on your Linux system
$ ulimit -s
8192        ← 8192 KB = 8 MB (default on most distributions)

## Or with prlimit (more detailed):
$ prlimit --stack --pid $$
RESOURCE  DESCRIPTION               SOFT      HARD UNITS
STACK     max stack size            8192 unlimited kbytes

Where Does the main() Thread Stack Live?

The main() thread is special. Its stack is placed by the kernel near the very top (high end) of the user VAS — just below where environment variables and command-line arguments are stored. If a process is single-threaded (only main()), it has exactly one user space stack, located at the high end of the address space.

For threads created later using pthread_create(), the C library allocates their stacks at arbitrary locations in the VAS (typically in the middle range, carved out of the available virtual address space using mmap()).

How Stacks Are Created: fork() vs pthread_create()

Understanding how thread stacks are created is important for Linux kernel programming because it reveals the unified mechanism the kernel uses for both processes and threads.

The fork() System Call Path

When a new process is created using fork(), the kernel:

1. Creates a new task_struct for the child process.
2. Copies (or sets up copy-on-write references to) the parent’s VAS.
3. The child gets a new VAS — a fresh copy of the parent’s user space, including a copy of the stack.

In modern Linux 6.x, fork() goes through this kernel call path:

/* Linux 6.x fork() call path */
sys_fork()
  └─► kernel_clone()          /* renamed from _do_fork() in Linux 5.10 */
        └─► copy_process()
              └─► dup_task_struct()   /* allocates new task_struct + kernel stack */
              └─► copy_mm()           /* sets up new VAS (COW for fork) */

The pthread_create() Path

When you call pthread_create() in your C program, it does not go through fork(). Instead, the POSIX threads library (libpthread, or the newer NPTL implementation built into glibc) calls the Linux-specific clone(2) system call directly.

The key difference is in the clone_flags parameter passed to clone(). For threads, flags like CLONE_VM, CLONE_FS, CLONE_FILES, CLONE_SIGHAND are set, which tell the kernel to share the VAS, filesystem context, file descriptors, and signal handlers with the parent. This is what makes a thread a thread — it reuses the parent’s VAS instead of creating a new one.

/* Simplified: what pthread_create does under the hood */
clone(CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD | ...,
      child_stack_ptr,   /* pointer to newly allocated thread stack */
      &tid,
      NULL,
      NULL);

/* Inside the kernel, clone() calls kernel_clone() with these flags.
   CLONE_VM means: don't copy the VAS, share it.
   The new task_struct points to the SAME mm_struct as the parent. */

/* Minimal example: creating a thread and checking it in /proc */
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>

void *worker(void *arg)
{
    printf("Thread TID = %d, PID = %d\n", gettid(), getpid());
    sleep(30);   /* stay alive so we can inspect /proc */
    return NULL;
}

int main(void)
{
    pthread_t t;
    pthread_create(&t, NULL, worker, NULL);
    printf("Main  TID = %d, PID = %d\n", gettid(), getpid());
    pthread_join(t, NULL);
    return 0;
}

## Compile and run:
$ gcc -o thread_demo thread_demo.c -lpthread
$ ./thread_demo &
Main  TID = 5021, PID = 5021
Thread TID = 5022, PID = 5021   ← same PID, different TID

## View the VAS of the main thread (same mm for both):
$ cat /proc/5021/maps | grep stack
7f3b00000000-7f3b00021000 rw-p 00000000 00:00 0   [stack]        ← main stack
7f3affc00000-7f3affd00000 rw-p 00000000 00:00 0                  ← thread-1 stack (mmap'd)

Kernel Space Organization: task_struct and Kernel Stacks

So far we have looked at user space. Now let’s cross into kernel space — the half of the VAS that only the kernel can access. This is where the kernel manages per-process and per-thread state.

What is task_struct?

Every thread in Linux — whether it is a user-mode thread or a kernel thread — is represented internally by a task_struct. This is the central data structure of the Linux process management subsystem. It contains everything the kernel needs to know about a running thread: its state, its scheduling priority, its memory mappings (via a pointer to mm_struct), its file descriptors, its signal handlers, its credentials, and much more.

The Kernel Stack — Separate from the User Stack

Every thread has two stacks: the user space stack (which we already covered) and a kernel stack. These are completely separate. The kernel stack is allocated in kernel space when the task_struct is created, and it is used whenever the thread enters the kernel — for example, during a system call, an interrupt, or a page fault.

The kernel stack is much smaller than the user stack. On most architectures, the default kernel stack size in Linux 6.x is 16 KB per thread (two physical pages on x86-64 with 4 KB pages). This is intentionally small to reduce memory usage when thousands of threads exist. A key principle of Linux kernel programming is: never allocate large data structures on the kernel stack.

Kernel Threads — Threads Without User Space

Not all threads on a Linux system come from user programs. The kernel itself creates its own threads — called kernel threads — to perform background work like memory management (kswapd), disk I/O (kworker), soft IRQ processing (ksoftirqd), and RCU callbacks (rcu_preempt).

Kernel threads are special: they have a task_struct and a kernel stack, but they have no user space VAS. Their mm pointer in task_struct is NULL. You can see them in the output of ps — they appear with square brackets around their name:

## List kernel threads on a Linux 6.x system
$ ps aux | awk '$1=="root" && $11~/^\[/ {print $11}' | head -15