Unlocking Linux Memory: How mmap Works and When to Use It

1. mmap system call

mmap maps a file or other object into a process's virtual memory. The file is divided into pages; any unused space in the final page is zero‑filled. munmap performs the opposite operation, removing a specific address range mapping.

After mapping, the process can read or write the file directly via the virtual address without invoking read or write. Writes beyond the current file size are not persisted.

Shared‑memory communication via mmap is efficient because it avoids the multiple copies required by pipes or message queues.

Usage:

#include <sys/mman.h>
void *mmap(void *start, size_t length, int prot, int flags,
           int fd, off_t offset);
int munmap(void *start, size_t length);

Return values:

On success, mmap returns the address of the mapped region; munmap returns 0.

On failure, mmap returns MAP_FAILED ((void *)-1) and munmap returns -1, setting errno to one of the following:

EACCES – permission denied

EAGAIN – file locked or insufficient memory

EBADF – invalid file descriptor

EINVAL – invalid arguments

ENFILE – system file‑open limit reached

ENODEV – filesystem does not support mapping

ENOMEM – insufficient memory or too many mappings

EPERM – operation not permitted

ETXTBSY – file opened for writing with MAP_DENYWRITE

SIGSEGV – write to read‑only region

SIGBUS – access to unmapped memory

Parameters:

start : desired start address (usually NULL).

length : size of the mapping.

prot : protection flags – PROT_READ, PROT_WRITE, PROT_EXEC, PROT_NONE.

flags : mapping type and sharing options, e.g., MAP_SHARED, MAP_PRIVATE, MAP_ANONYMOUS, MAP_FIXED, etc.

fd : file descriptor (use -1 with MAP_ANONYMOUS).

offset : offset within the file where mapping starts.

2. munmap system call

#include <sys/mman.h>
int munmap(void *addr, size_t len);

This call removes a mapping from the process address space. After unmapping, any access to the former region triggers a segmentation fault.

3. msync system call

#include <sys/mman.h>
int msync(void *addr, size_t len, int flags);

Changes made to a shared mapping are not written back to the underlying file until munmap or msync is called. msync forces synchronization of the mapped region with the file on disk.

4. Two ways to use mmap for shared memory

(1) File‑backed mapping : Open or create a regular file, then map it with mmap. Example:

fd = open(name, flag, mode);
if (fd < 0) {
    /* handle error */
}
ptr = mmap(NULL, len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

(2) Anonymous mapping : Suitable for related processes (e.g., parent‑child). The parent calls mmap with MAP_ANONYMOUS, then fork(). The child inherits the same address space, allowing both processes to communicate via the shared region.

5. How mmap works internally

The goal of mmap is to map a device or file into a process's virtual address space, enabling direct read/write. The operation involves three steps:

Find a contiguous free virtual address range in the user space (performed by the kernel).

Establish a vm_area_struct that describes the region and its attributes.

Link the virtual region to the physical pages via page‑table updates performed by the device driver.

Each process typically has a 3 GB user virtual space. The kernel represents each mapped region with a struct vm_area_struct:

#include <linux/mm_types.h>
struct vm_area_struct {
    struct mm_struct *vm_mm;
    unsigned long vm_start;
    unsigned long vm_end;
    struct vm_area_struct *vm_next;
    pgprot_t vm_page_prot;
    unsigned long vm_flags;
    short vm_avl_height;
    struct vm_area_struct *vm_avl_left;
    struct vm_area_struct *vm_avl_right;
    struct vm_operations_struct *vm_ops;
    unsigned long vm_pgoff;
    struct file *vm_file;
    unsigned long vm_raend;
    void *vm_private_data;
};

When many vm_area_struct instances exist, the kernel augments the linked‑list with an AVL tree (using vm_avl_height, vm_avl_left, vm_avl_right) to speed up lookups.

For file‑backed mappings, vm_file points to the file's struct file, and vm_pgoff stores the offset within the file.

During the first access to a newly mapped area, a page‑fault occurs. The kernel then:

Searches the page cache (or swap cache) for the required page.

If absent, reads the page from disk (for file‑backed mappings) or allocates a new physical page (for anonymous mappings).

Updates the process's page tables so subsequent accesses hit the resident page.

All processes sharing the same mapped region ultimately reference the same physical page, ensuring coherent shared‑memory communication.