VOP_GETPAGES(9)

💅 VOP_GETPAGES — read or write VM pages from a file ✨

okay so bestie, welcome to the kernel dev manual, VOP_GETPAGES(9) edition 🎀 this is the page about VOP_GETPAGES and VOP_PUTPAGES, and it's literally the vibe check for how virtual memory pages get read from and written to files. buckle up, it's giving low-level but make it cute 💖

---

✨ SYNOPSIS ✨

#include <sys/param.h>
#include <sys/vnode.h>
#include <vm/vm.h>

int
VOP_GETPAGES(struct vnode *vp, vm_page_t *ma, int count, int *rbehind,
    int *rahead);

int
VOP_PUTPAGES(struct vnode *vp, vm_page_t *ma, int bytecount, int flags,
    int *rtvals);

---

🌸 DESCRIPTION 🌸

So the VOP_GETPAGES() method is what gets called to read in pages of virtual memory that are backed by ordinary files, no cap. And if there are other adjacent pages backed by adjacent regions of the same file, VOP_GETPAGES() gets asked to read those too — although honestly it's not required to 🙈. The VOP_PUTPAGES() method is the converse, i.e. it writes out adjacent dirty pages of virtual memory. periodt.

On entry, the vnode lock is held but neither the page queue nor the VM object locks are held 🔒. Both methods return in the same state on both success and error returns — so like, no surprise plot twists at the end.

Here's the cast of arguments, main character energy only:

• vp — the file to access. the file in question, the one we're stanning.
• ma — pointer to the first element of an array of pages representing a contiguous region of the file to be read or written 📚.
• count — the length of the ma array.
• bytecount — the number of bytes that should be written from the pages of the array.
• flags — a bitfield of flags affecting the function operation. let's break it down:
  • if VM_PAGER_PUT_SYNC is set, the write should be synchronous; control must not be returned to the caller until after the write is finished ⏳.
  • if VM_PAGER_PUT_INVAL is set, the pages are to be invalidated after being written.
  • if VM_PAGER_PUT_NOREUSE is set, the I/O performed should set the IO_NOREUSE flag, to indicate to the filesystem that pages should be marked for fast reuse if needed. this could occur via a call to vm_page_deactivate_noreuse(9), which puts such pages onto the head of the inactive queue 👑.
  • if VM_PAGER_CLUSTER_OK is set, writes may be delayed, so that related writes can be coalesced for efficiency, e.g., using the clustering mechanism of the buffer cache 🔥.
• rtvals — an array of VM system result codes indicating the status of each page written by VOP_PUTPAGES().
• rbehind — optional pointer to integer specifying number of pages to be read behind, if possible. if the filesystem supports that feature, the number of actually read pages is reported back, otherwise zero is returned.
• rahead — optional pointer to integer specifying number of pages to be read ahead, if possible. if the filesystem supports that feature, the number of actually read pages is reported back, otherwise zero is returned.

---

🦋 the status values 🦋

The status of the VOP_PUTPAGES() method is returned on a page-by-page basis in the array rtvals[]. the possible status values are, and I cannot stress this enough, these exact ones:

• VM_PAGER_OK — the page was successfully written 🎉. the implementation must call vm_page_undirty(9) to mark the page as clean.
• VM_PAGER_PEND — the page was scheduled to be written asynchronously. when the write completes, the completion callback should call vm_object_pip_wakeup(9) and vm_page_sunbusy(9) to clear the busy flag and awaken any other threads waiting for this page, in addition to calling vm_page_undirty(9) 😴.
• VM_PAGER_BAD — the page was entirely beyond the end of the backing file. this condition should not be possible if the vnode's file system is correctly implemented 💀.
• VM_PAGER_ERROR — the page could not be written because of an error on the underlying storage medium or protocol 😭.
• VM_PAGER_FAIL — treated identically to VM_PAGER_ERROR. same energy, different name.
• VM_PAGER_AGAIN — the page was not handled by this request 🙈.

---

💜 the rules for VOP_GETPAGES() 💜

The VOP_GETPAGES() method must populate and validate all requested pages in order to return success. it's expected to release any pages in ma that it does not successfully handle, by calling vm_page_free(9). when it succeeds, VOP_GETPAGES() must set the valid bits appropriately ✨.

Upon entry to VOP_GETPAGES(), all pages in ma are busied exclusively. upon successful return, the pages must all be busied exclusively as well, but pages may be unbusied during processing. and the filesystem is responsible for activating paged-out pages — though this does not necessarily need to be done within VOP_GETPAGES() depending on the architecture of the particular filesystem 🧚.

lowkey important: "must populate and validate all requested pages" is not a suggestion, bestie. it's a whole requirement. no half-effort slay here.

---

⭐ RETURN VALUES ⭐

If it successfully reads all pages in ma, VOP_GETPAGES() returns VM_PAGER_OK; otherwise, it returns VM_PAGER_ERROR. by convention, the return value of VOP_PUTPAGES() is rtvals[0] 👑. that's it, that's the whole return values section, and honestly? iconic.

---

🌈 SEE ALSO 🌈

vm_object_pip_wakeup(9), vm_page_free(9), vm_page_sunbusy(9), vm_page_undirty(9), vm_page_xunbusy(9), vnode(9) — go read those too, iykyk 🫶

---

🎀 AUTHORS 🎀

This manual page was written by Doug Rabson and then substantially rewritten by Garrett Wollman. absolute legends, both of them 💅

---

and that's the whole page, bestie!! 🍓 this was VOP_GETPAGES(9) from the Kernel Developer's Manual, coming at you from Debian, dated June 29, 2019 🌸 mwah, go read your VM code, ily 💖