filemap_fault(9)

📦 version 7.3.1, in nixpkgs unstable

💖 NAME 💖

filemap_fault — bestie, this is the one that reads in your file data when a page fault comes knocking ✨

(also hi, you're in the Kernel API Manual, section 9, and this whole page is literally about filemap_fault 🫶)

🌸 SYNOPSIS 🌸

vm_fault_t filemap_fault (struct vm_fault *vmf );

🎀 ARGUMENTS 🎀

  • vmf — a struct vm_fault that's carrying all the deets of the fault 💅 like, every little detail of what went down, packed into one struct

✨ DESCRIPTION ✨

Okay so picture this: filemap_fault gets invoked via the vma operations vector for a mapped memory region, and its whole job is to read in file data during a page fault. That's it, that's the gig 👑

And ngl, the goto's are kind of ugly 😭 but they streamline the normal case of having it in the page cache, and handle the special cases reasonably without having a lot of duplicated code. So like… yeah. Iconic tradeoff, fr fr.

⚠️ IMPORTANT LORE ⚠️ vma->vm_mm->mmap_lock must be held on entry. No exceptions, bestie. Hold the lock 💀

Now for the return-value tea ☕ because this is the part where you really gotta pay attention:

  • If our return value has VM_FAULT_RETRY set, it's because the mmap_lock may be dropped before doing I/O or by lock_folio_maybe_drop_mmap.
  • If our return value does not have VM_FAULT_RETRY set, the mmap_lock has not been released.
  • We never return with VM_FAULT_RETRY and a bit from VM_FAULT_ERROR set. Never ever. That combo is not a thing 🚫

🌈 RETURN 🌈

A bitwise-OR of VM_FAULT_ codes 🎁 (yes, the whole bouquet of them, OR'd together, slay)

💜 SEE ALSO 💜

The kernel file in question: ./mm/filemap.c 🦋

And here's the whole friend group, no cap — every single one of them 🫶

✿ k bye ily, go read your file data ✿

This little page came from the ./mm source and it's dated October 2026 🗓️💖 mwah, catch you on the next fault 🧚‍♀️

📦 where this page comes from