Analysis of Linux mmap File Read Process and Page Fault Handling

In a previous article the definition, read flow, and write flow of the Linux kernel file cache were introduced. This article continues the discussion by focusing on the file read process via mmap and the associated page‑fault handling.

The mmap system call maps a file into the user‑space address range, allowing the process to access file contents as ordinary memory. The article explains the parameters of mmap (addr, length, prot, flags, fd, offset) and points readers to man mmap for details.

The lifecycle of an mmap call is described as follows:

ksys_mmap_pgoff in the kernel entry point.

Acquisition of a virtual address via get_unmapped_area .

Creation of a vm_area_struct (VMA) with vm_area_alloc and initialization of its fields.

Invocation of the file system’s mmap operations through call_mmap (e.g., ext4’s mmap implementation).

After the VMA is established, the mapped region contains no physical pages. When the process accesses the virtual address, the MMU triggers a page‑fault because the address is not backed by physical memory.

The page‑fault handling proceeds through several stages:

The hardware raises a data‑abort interrupt, which the kernel handles in do_DataAbort (ARM architecture).

The fault information (FSR and FAR registers) is processed, and do_page_fault calls __do_page_fault to locate the relevant VMA.

handle_mm_fault allocates a page table entry and dispatches to handle_pte_fault , which eventually calls do_fault for file‑backed pages.

filemap_fault (defined in mm/memory.c ) checks whether the page is already in the file cache and decides between synchronous or asynchronous readahead.

The article also outlines the two readahead strategies:

do_async_mmap_readahead – used when the previous access hit a page that was prefetched asynchronously.

do_sync_mmap_readahead – performs synchronous readahead when the page is not present in the cache.

The munmap system call is covered next. Its simple lifecycle consists of locating the VMA for the given address, calling unmap_region to remove the mapping and free page tables, and finally removing the VMA from the process’s mm_struct with remove_vma_list . The article notes that unmapping does not immediately free the file cache because the pages may still be referenced by other processes or retained by the kernel until memory pressure triggers reclamation.

Finally, the article mentions that the file‑cache reclamation process involves LRU, working‑set, shrinker, and dirty‑page mechanisms, which will be explored in a future “File cache reclamation” installment.