A synthesis of how a process/thread is represented, how fork and pthread_create differ, how libraries and files are wired, and the kernel structs behind it all. Companion to the mb_labs; each section notes the lab that exercises it.

  PROCESS WORLD (MM)                          FILESYSTEM WORLD (VFS)
  per-process (threads share one set)         nobody's -- shared by all

  +-----------------------------+
  |        task_struct          |
  |     thread / scheduling     |
  +--------------+--------------+
                 | mm
                 v
  +-----------------------------+
  |         mm_struct           |
  |       address space         |
  +--------------+--------------+
                 | mmap  (the VMA list)
                 v
  +-----------------------------+   vm_file    +-----------------------------+
  |       vm_area_struct        |------------->|         struct file         |
  |        VMA  (+ vm_file)      |              |     an open-file instance   |
  +-----------------------------+              +--------------+--------------+
                                                              | f_inode / f_mapping
                                                              v
                                               +-----------------------------+
                                               |            inode            |
                                               |   metadata + address_space  |
                                               |       (the page cache)      |
                                               +-----------------------------+

• Left = the MM (process) world — task_struct -> mm_struct -> vm_area_struct. Per-process: each process has its own mm and VMAs (threads of a process share one set; separate processes each have their own).
• Right = the VFS (filesystem) world — struct file -> inode -> page cache. Nobody's / shared: one inode (and its page cache) is shared by everyone who maps or opens that file.
• vm_file is the bridge: a file-backed VMA points into the VFS world, so the region's pages come from that file's page cache — which is how a shared .so ends up as one physical copy behind many processes' private VMAs. Anonymous VMAs (heap/stack) have vm_file == NULL and stay entirely in the MM world (no VFS side).

Reading /proc/<pid>/maps walks the left column (mm->mmap) and, for each VMA, follows vm_file into the right column to print the file's dev/inode + path.

   fork()                              pthread_create()
     |  glibc                             |  glibc
     v                                    v
   clone(SIGCHLD)                       clone(CLONE_VM | CLONE_FILES | CLONE_FS |
   (no sharing flags)                         CLONE_SIGHAND | CLONE_THREAD |
     |                                        CLONE_SETTLS | ...)
     v                                    v
   kernel: copy_process() -> new task_struct; per resource: SHARE or COPY

copy_process()

/* simplified from kernel/fork.c */
static int copy_mm(unsigned long clone_flags, struct task_struct *tsk)
{
    if (clone_flags & CLONE_VM) {
        mm = oldmm;              /* SHARE: same mm_struct, bump refcount  (pthread) */
        atomic_inc(&mm->mm_users);
    } else {
        mm = dup_mm(tsk, oldmm); /* COPY: new mm_struct, COW page tables  (fork)    */
    }
    tsk->mm = mm;
}

Rule in copy_process(): flag set (1) -> share the pointer; flag clear (0) -> copy.

• fork: new task_struct, own mm (copied, COW), new tgid -> a PROCESS.
• pthread: new task_struct, shared mm (same pointer), same tgid -> a THREAD.
• The kernel schedules both identically as tasks; everything else falls out of the mm decision.

Identity: getpid() == kernel tgid (process); gettid() == kernel pid (thread). The word "pid" flips meaning between layers. (Lab: procthread_lab.)

task_struct   -- ONE per thread (the schedulable entity)
  |- state, flags(PF_KTHREAD), pid, tgid, comm[16], real_parent, group_leader
  |- stack ------> kernel stack
  |- mm ---------> mm_struct        (address space; NULL for kthreads)
  |- active_mm --> installed mm     (kthreads borrow one)
  |- files ------> files_struct     (fd table)
  |
  (mm) mm_struct  -- ONE per process (shared by its threads)
        |- mmap ------> vm_area_struct   (head of the VMA list)
        |- mm_rb -----> rbtree of the VMAs (fast find_vma)
        |- pgd -------> page tables (-> TTBR0)
        |- mm_users --> # threads sharing it
        |- map_count, mmap_sem, start_code/start_stack ...
        |
        (mmap) vm_area_struct  -- ONE per memory region
                |- vm_start, vm_end   the VA range [start,end)
                |- vm_flags           VM_READ/WRITE/EXEC/SHARED
                |- vm_page_prot       -> PTE permission bits
                |- vm_file            backing struct file (NULL = anonymous)
                         |- f_path {mnt,dentry} -> pathname -> /proc maps
                         |- f_op -> file_operations (.read/.write/.mmap)
                         |- f_inode ----------> struct inode
                                                 |- i_ino      -> /proc maps "inode"
                                                 |- s_dev      -> /proc maps "dev"
                                                 |- i_mapping -> address_space (PAGE CACHE)
                |- vm_pgoff           offset into vm_file
                |- vm_ops             .fault/.open/.close handlers
                |- vm_next/prev, vm_rb, vm_mm

• task_struct = the thread: identity + pointers. mm NULL for kthreads.
• mm_struct = the address space: page tables (pgd) + the list of VMAs (mmap). Shared by threads (CLONE_VM), copied by fork.
• vm_area_struct (VMA) = one contiguous region with uniform perms/backing. A .so = several VMAs (text r-xp shared, data rw-p COW).
• files_struct = the fd table (array of struct file *).
• struct file = one open-file instance (offset, flags, f_op); your char devices' .read/.write/.mmap are reached through it.

Labs: pid/tgid/comm/mm -> procthread_lab,current_lab,findtask_lab; mm->mmap/VMAs -> vma_lab; pgd/page tables -> ptwalk_lab; vm_ops/.mmap -> mmap_lab; struct file/file_operations -> procfs/sysfs/mmap/procthread labs.

A .so's read-only text is mapped shared across every process using it -> one physical copy via the page cache. Writable data is COW (per-process).

A .ko resolves undefined symbols against the kernel symbol table (only EXPORT_SYMBOLed ones) + loaded modules; CRC (modversions) guards the ABI. "Unknown symbol" = the needed export isn't present (e.g. IRQ_SIM before built in). Bridge: the vDSO (linux-vdso.so.1) is a kernel-provided .so mapped into every process for fast syscalls.

task_struct has no "library" concept. ld.so mmap()s the .so, creating file-backed VMAs in the process's mm:

Process A                          Process B
 mm_A (own VMA list)                mm_B (own VMA list)
   libc VMA_A  vm_start=0x7fAA..      libc VMA_B  vm_start=0x7fBB..  (ASLR: may differ)
   vm_file --\                        vm_file --\
              \----------- struct file / inode: /lib/libc.so ----------/
                                   |
                                   v
                        page cache: libc text pages  (ONE physical copy)
                          /                       \
                   A page tables            B page tables   (map to SAME phys pages)

• The VMA is per-process (own descriptor, own virtual address; .so must be PIC so any load address works). The file + physical pages are shared.
• Execution is demand paging: PC jumps into the text VMA -> page fault -> find_vma sees a file-backed VMA -> read the page from vm_file via the page cache -> shared across all mappers. (Lab: ptwalk_lab walks these page tables.)
• Symbols/relocations (PLT/GOT) are entirely userspace ld.so work; the kernel only ever sees file-backed memory mappings.

Threads vs processes here: threads share the mm -> the same VMA list and same virtual addresses (one mapping). Processes have separate mms -> separate VMAs that merely point their vm_file at the same file. Both share the .so's physical pages; only threads share the mapping itself.

/proc/<pid>/maps is the human-readable dump of that process's VMA list — the kernel walks mm->mmap and prints one line per vm_area_struct. This is the same data vma_lab printed from inside the kernel. Real excerpt (cat /proc/self/maps):

address                  perms offset   dev   inode     pathname
558c2143b000-558c2143f000 r-xp 00002000 00:3e 6760083   /usr/bin/cat          <- app text
558c21442000-558c21443000 rw-p 00008000 00:3e 6760083   /usr/bin/cat          <- app data
558c33d12000-558c33d33000 rw-p 00000000 00:00 0         [heap]                <- anonymous
7fb40e5b5000-7fb40e5dd000 r--p 00000000 00:3e 7795433   .../libc.so.6         <- libc header
7fb40e5dd000-7fb40e772000 r-xp 00028000 00:3e 7795433   .../libc.so.6         <- libc TEXT (shared RO)
7fb40e772000-7fb40e7ca000 r--p 001bd000 00:3e 7795433   .../libc.so.6         <- libc rodata
7fb40e7ca000-7fb40e7cb000 ---p 00215000 00:3e 7795433   .../libc.so.6         <- guard (no access)
7fb40e7cf000-7fb40e7d1000 rw-p 00219000 00:3e 7795433   .../libc.so.6         <- libc data (COW)

Each column maps straight to a vm_area_struct field:

What this shows about the .so:

• One library = several VMAs — libc appears as ~5 lines (header r--p, TEXT r-xp, rodata r--p, a ---p guard, data rw-p). Same inode (7795433) = the same file split by segment permissions.
• The r-xp text line is the shared, read-only, executable mapping — one physical copy across every process (same inode, page cache). The rw-p data line is COW/private.
• inode 0 / no path = anonymous ([heap], [stack], or bare rw-p) — vm_file == NULL.
• Compare two processes: grep libc /proc/PID1/maps /proc/PID2/maps — same inode, possibly different start addresses (ASLR), proving per-process VMA + shared file.

Related views:

• cat /proc/<pid>/smaps — per-VMA detail: Rss, Pss (proportional set size — splits shared pages across sharers), Shared_Clean vs Private_Dirty; this is where you see the .so text counted as shared.
• pmap -x <pid> — the same as a table with sizes.
• The kernel prints each line in fs/proc/task_mmu.c:show_map_vma() by walking mm->mmap; vma_lab did the equivalent walk directly.

userspace:  fd = open("/dev/x");  write(fd, ...)
                |  (fd = index)
                v
 task_struct.files -> files_struct        (the fd TABLE: array of struct file*)
                        fd[3] -> struct file   (one open: offset, flags, f_op)
                                   f_op -> file_operations  (.open/.read/.write/.mmap)
                                             |
                                             v
 kernel:  YOUR handler runs (procthread_lab pt_write, mmap_lab .mmap)
          struct file -> inode (the file) -> dentry (its name)   [VFS]

• fd is just an index into the process's files_struct.
• The fd table is the files row of the fork/pthread table: threads share one files_struct; fork copies it (but entries point at the same struct file, so inherited fds share the offset).
• Every char-device lab plugs into this VFS path via the file_operations it registers.

Symptom -> tool:

gdb — the workhorse

• threads: info threads, thread N, thread apply all bt (every thread's stack — the #1 deadlock tool), break f:line thread N, set scheduler-locking on.
• processes: set follow-fork-mode child, set detach-on-fork off, info inferiors / inferior N, catch fork, attach <pid>.

Bug detectors (rebuild with a sanitizer; fast + precise)

• TSan -fsanitize=thread — data races (unsynchronised shared access).
• ASan -fsanitize=address — overflows, use-after-free.
• Valgrind --tool=helgrind (races + ABBA lock-order, no rebuild, slow), --tool=drd (races + contention), default = Memcheck (memory).

Live introspection (no rebuild)

• gstack <pid> / pstack <pid> — one-shot dump of all thread stacks.
• ps -eLf, top -H, pstree -tp (threads in {braces}).
• /proc/<pid>/task/<tid>/ — per-thread; wchan = what it's blocked in; status has Threads:.

Tracing / profiling: strace -f (per-thread syscalls), perf record -g (CPU), perf sched latency (scheduling delay), off-CPU with bpftrace.

Post-mortem: ulimit -c unlimited; gdb ./prog core -> thread apply all bt.

Learn two first: gdb's thread apply all bt (most hangs, minutes) and ThreadSanitizer (the races behind "impossible" bugs). A TSan report is an unprotected atomics_lab-style access; a deadlock in thread apply all bt is the userspace lockdep_lab/ABBA cycle.

A process is a task_struct whose mm points to an mm_struct (page tables + a list of vm_area_struct regions). fork copies the mm (own address space, new tgid -> process); pthread_create shares it (same mm, same tgid -> thread). A shared library is not referenced as a "library" — ld.so mmaps it into file-backed VMAs (vm_file -> the .so), so each process has its own mapping but they all fault onto the same page-cache pages. Files reach kernel code through the VFS: an fd indexes files_struct -> a struct file -> your file_operations. Userspace uses static (.a, copied in) or dynamic (.so, shared) libs; the kernel uses built-in (obj-y) or modules (.ko, linked against exported symbols) — no libc. The kernel schedules threads and processes identically as tasks; every difference you observe flows from whether the mm (and tgid) is shared or copied.